From 579fa629e36d094f30f690dccd6ab7e419bd0ccc Mon Sep 17 00:00:00 2001 From: protectionsmachine <72879786+protectionsmachine@users.noreply.github.com> Date: Tue, 25 Jun 2024 12:48:54 +0000 Subject: [PATCH 1/2] [Security Rules] Update security rules package to v8.14.4-beta.1 --- .../security_detection_engine/changelog.yml | 5 + ...9cab4-dbbd-4a3f-9e8e-1287c7c11ae5_106.json | 67 ++++++ ...c41e478-5263-4c69-8f9e-7dfd2c22da64_7.json | 142 ++++++++++++ ...c5dd5-838b-446e-b1ac-c995c7f8108a_105.json | 80 +++++++ ...1d055-5c66-4adf-9c59-fc0fa58336a5_105.json | 78 +++++++ ...1d055-5c66-4adf-9c71-fc0fa58338c7_104.json | 72 ++++++ ...1d055-5c66-4adf-9d60-fc0fa58337b6_105.json | 73 ++++++ ...1d055-5c66-4adf-9d82-fc0fa58449c8_104.json | 59 +++++ ...1d055-5c66-4adf-9e93-fc0fa69550c9_104.json | 66 ++++++ ...68559-b274-4948-ad0b-f8415bb31126_104.json | 43 ++++ ...92657ba-ab0e-4901-89a2-911d611eee98_2.json | 166 ++++++++++++++ ...e8096-e2b0-4bd8-80c9-34a820813fff_209.json | 43 ++++ ...fc667-9ff1-4b33-9f40-fefca8537eb0_104.json | 77 +++++++ ...ec04b-d902-4f89-8aff-92cd9043c16f_104.json | 69 ++++++ ...3f18264-2d6d-11ef-9413-f661ea17fbce_1.json | 75 +++++++ ...6e1bc-867a-11ee-b13e-f661ea17fbcd_101.json | 60 +++++ ...86980-1fb1-4dff-b311-3be941549c8d_104.json | 43 ++++ ...a657da0-1df2-11ef-a327-f661ea17fbcc_1.json | 97 ++++++++ ...e32e6-6104-46d9-a06e-da0f8b5795a0_104.json | 47 ++++ ...0272b-9724-4bc6-a3ca-f1532b81e5c2_104.json | 66 ++++++ ...a342e-03fb-42d0-8656-0367eb2dead5_105.json | 95 ++++++++ ...804f5-b289-43d6-a881-9387cf594f75_105.json | 73 ++++++ ...834ca-f861-414c-8602-150d5505b777_102.json | 74 +++++++ ...fbdc5-db15-485e-bc24-f5707f820c4b_104.json | 45 ++++ ...7bfa0a9-37c0-44d6-b724-54bf16787492_1.json | 109 +++++++++ ...56272-1998-4b8c-be14-e287035c4d10_105.json | 62 ++++++ ...83105-4681-46c3-9890-0c66d05e776b_104.json | 62 ++++++ ...d676480-9655-4507-adc6-4eec311efff8_1.json | 98 ++++++++ ...fc812-7996-4795-8869-9c4ea595fe88_105.json | 74 +++++++ ...96015ef-718e-40ff-ac4a-cc2ba88dbeeb_1.json | 87 ++++++++ ...48b96-c922-4adb-b51c-b767f1ea5b76_109.json | 74 +++++++ ...0d56f-5c0e-4ac6-aece-bee96645b172_106.json | 89 ++++++++ ...b0119-0560-43ba-860a-7235dd8cee8d_105.json | 68 ++++++ ...edc4c-c54c-49c6-97a1-651223819448_104.json | 68 ++++++ ...3d8d9-b476-451d-a9e0-7a5addd70670_209.json | 43 ++++ ...b70d3-e2c3-455e-af1b-2626a5a1a276_209.json | 43 ++++ ...94326d2-56c0-4342-b553-4abfaf421b5b_1.json | 88 ++++++++ ...02f01-969f-4167-8d77-07827ac4cee0_104.json | 68 ++++++ ...02f01-969f-4167-8f55-07827ac3acc9_104.json | 68 ++++++ ...02f01-969f-4167-8f66-07827ac3bdd9_104.json | 61 +++++ ...75852-b0f5-4b8b-89c3-a226efae5726_207.json | 113 ++++++++++ ...4e734c0-2cda-11ef-84e1-f661ea17fbce_1.json | 75 +++++++ ...5b99adc-2cda-11ef-84e1-f661ea17fbce_1.json | 75 +++++++ ...cf974-6587-4f65-9252-d866a3fdfd9c_105.json | 68 ++++++ ...02377-d226-4e12-b54c-1906b5aec4f6_104.json | 69 ++++++ ...61809f3-fb5b-465c-8bff-23a8a068ac60_7.json | 127 +++++++++++ ...ab184d3-72b3-4639-b242-6597c99d8bca_8.json | 209 ++++++++++++++++++ ...e61a8-c560-4dbd-acca-1e1438bff36b_104.json | 69 ++++++ ...06eae-d5ec-4b14-b4fd-e8ba8086f0e1_209.json | 43 ++++ ...0bfb8-26b7-4e5e-924e-218144a3fa71_104.json | 43 ++++ ...7b919-665f-4aac-b9e8-68369bf2340c_104.json | 66 ++++++ ...66b7e2b-d50a-49b9-a6fc-3a383baedc6b_1.json | 142 ++++++++++++ ...42eb2-583c-439f-b04d-1fdd7c1417cc_104.json | 48 ++++ ...c4d8c-f014-40ef-88b6-79a1d67cd499_104.json | 62 ++++++ ...b5533-ca2a-41f6-a8b0-ee98abe0f573_105.json | 44 ++++ ...6a419-9b3f-4f57-8ff8-ac4cd2d5f530_104.json | 69 ++++++ ...f3a06-1e0a-48ec-b96a-faf2309fae46_104.json | 62 ++++++ ...73fa0-9d43-465e-b8bf-50230da6718b_104.json | 66 ++++++ ...5c059-c19a-4a96-8ae3-41496ef3bcf9_104.json | 66 ++++++ ...93e61db-82d6-4095-99aa-714988118064_1.json | 129 +++++++++++ ...28dee-c999-400f-b640-50a081cc0fd1_209.json | 43 ++++ ...97323-72a8-46a9-a08e-3f5b04a4a97a_104.json | 69 ++++++ ...aed74-c816-40d3-a810-48d6fbd8b2fd_105.json | 96 ++++++++ ...77d63-9679-4ce3-be25-3ba8b795e5fa_104.json | 43 ++++ ...3e22c8b-ea47-45d1-b502-b57b6de950b3_7.json | 137 ++++++++++++ ...90f47-6bd5-4a49-bd49-a2f886476fb9_105.json | 62 ++++++ .../security_detection_engine/manifest.yml | 2 +- 67 files changed, 4973 insertions(+), 1 deletion(-) create mode 100644 packages/security_detection_engine/kibana/security_rule/0b29cab4-dbbd-4a3f-9e8e-1287c7c11ae5_106.json create mode 100644 packages/security_detection_engine/kibana/security_rule/0c41e478-5263-4c69-8f9e-7dfd2c22da64_7.json create mode 100644 packages/security_detection_engine/kibana/security_rule/138c5dd5-838b-446e-b1ac-c995c7f8108a_105.json create mode 100644 packages/security_detection_engine/kibana/security_rule/1781d055-5c66-4adf-9c59-fc0fa58336a5_105.json create mode 100644 packages/security_detection_engine/kibana/security_rule/1781d055-5c66-4adf-9c71-fc0fa58338c7_104.json create mode 100644 packages/security_detection_engine/kibana/security_rule/1781d055-5c66-4adf-9d60-fc0fa58337b6_105.json create mode 100644 packages/security_detection_engine/kibana/security_rule/1781d055-5c66-4adf-9d82-fc0fa58449c8_104.json create mode 100644 packages/security_detection_engine/kibana/security_rule/1781d055-5c66-4adf-9e93-fc0fa69550c9_104.json create mode 100644 packages/security_detection_engine/kibana/security_rule/17e68559-b274-4948-ad0b-f8415bb31126_104.json create mode 100644 packages/security_detection_engine/kibana/security_rule/192657ba-ab0e-4901-89a2-911d611eee98_2.json create mode 100644 packages/security_detection_engine/kibana/security_rule/19de8096-e2b0-4bd8-80c9-34a820813fff_209.json create mode 100644 packages/security_detection_engine/kibana/security_rule/1e9fc667-9ff1-4b33-9f40-fefca8537eb0_104.json create mode 100644 packages/security_detection_engine/kibana/security_rule/1faec04b-d902-4f89-8aff-92cd9043c16f_104.json create mode 100644 packages/security_detection_engine/kibana/security_rule/23f18264-2d6d-11ef-9413-f661ea17fbce_1.json create mode 100644 packages/security_detection_engine/kibana/security_rule/2e56e1bc-867a-11ee-b13e-f661ea17fbcd_101.json create mode 100644 packages/security_detection_engine/kibana/security_rule/35f86980-1fb1-4dff-b311-3be941549c8d_104.json create mode 100644 packages/security_detection_engine/kibana/security_rule/3a657da0-1df2-11ef-a327-f661ea17fbcc_1.json create mode 100644 packages/security_detection_engine/kibana/security_rule/3c7e32e6-6104-46d9-a06e-da0f8b5795a0_104.json create mode 100644 packages/security_detection_engine/kibana/security_rule/4330272b-9724-4bc6-a3ca-f1532b81e5c2_104.json create mode 100644 packages/security_detection_engine/kibana/security_rule/445a342e-03fb-42d0-8656-0367eb2dead5_105.json create mode 100644 packages/security_detection_engine/kibana/security_rule/46f804f5-b289-43d6-a881-9387cf594f75_105.json create mode 100644 packages/security_detection_engine/kibana/security_rule/493834ca-f861-414c-8602-150d5505b777_102.json create mode 100644 packages/security_detection_engine/kibana/security_rule/52afbdc5-db15-485e-bc24-f5707f820c4b_104.json create mode 100644 packages/security_detection_engine/kibana/security_rule/57bfa0a9-37c0-44d6-b724-54bf16787492_1.json create mode 100644 packages/security_detection_engine/kibana/security_rule/59756272-1998-4b8c-be14-e287035c4d10_105.json create mode 100644 packages/security_detection_engine/kibana/security_rule/5c983105-4681-46c3-9890-0c66d05e776b_104.json create mode 100644 packages/security_detection_engine/kibana/security_rule/5d676480-9655-4507-adc6-4eec311efff8_1.json create mode 100644 packages/security_detection_engine/kibana/security_rule/647fc812-7996-4795-8869-9c4ea595fe88_105.json create mode 100644 packages/security_detection_engine/kibana/security_rule/696015ef-718e-40ff-ac4a-cc2ba88dbeeb_1.json create mode 100644 packages/security_detection_engine/kibana/security_rule/6d448b96-c922-4adb-b51c-b767f1ea5b76_109.json create mode 100644 packages/security_detection_engine/kibana/security_rule/6e40d56f-5c0e-4ac6-aece-bee96645b172_106.json create mode 100644 packages/security_detection_engine/kibana/security_rule/745b0119-0560-43ba-860a-7235dd8cee8d_105.json create mode 100644 packages/security_detection_engine/kibana/security_rule/746edc4c-c54c-49c6-97a1-651223819448_104.json create mode 100644 packages/security_detection_engine/kibana/security_rule/78d3d8d9-b476-451d-a9e0-7a5addd70670_209.json create mode 100644 packages/security_detection_engine/kibana/security_rule/809b70d3-e2c3-455e-af1b-2626a5a1a276_209.json create mode 100644 packages/security_detection_engine/kibana/security_rule/894326d2-56c0-4342-b553-4abfaf421b5b_1.json create mode 100644 packages/security_detection_engine/kibana/security_rule/91f02f01-969f-4167-8d77-07827ac4cee0_104.json create mode 100644 packages/security_detection_engine/kibana/security_rule/91f02f01-969f-4167-8f55-07827ac3acc9_104.json create mode 100644 packages/security_detection_engine/kibana/security_rule/91f02f01-969f-4167-8f66-07827ac3bdd9_104.json create mode 100644 packages/security_detection_engine/kibana/security_rule/93075852-b0f5-4b8b-89c3-a226efae5726_207.json create mode 100644 packages/security_detection_engine/kibana/security_rule/94e734c0-2cda-11ef-84e1-f661ea17fbce_1.json create mode 100644 packages/security_detection_engine/kibana/security_rule/95b99adc-2cda-11ef-84e1-f661ea17fbce_1.json create mode 100644 packages/security_detection_engine/kibana/security_rule/99dcf974-6587-4f65-9252-d866a3fdfd9c_105.json create mode 100644 packages/security_detection_engine/kibana/security_rule/9d302377-d226-4e12-b54c-1906b5aec4f6_104.json create mode 100644 packages/security_detection_engine/kibana/security_rule/a61809f3-fb5b-465c-8bff-23a8a068ac60_7.json create mode 100644 packages/security_detection_engine/kibana/security_rule/aab184d3-72b3-4639-b242-6597c99d8bca_8.json create mode 100644 packages/security_detection_engine/kibana/security_rule/abae61a8-c560-4dbd-acca-1e1438bff36b_104.json create mode 100644 packages/security_detection_engine/kibana/security_rule/ac706eae-d5ec-4b14-b4fd-e8ba8086f0e1_209.json create mode 100644 packages/security_detection_engine/kibana/security_rule/b240bfb8-26b7-4e5e-924e-218144a3fa71_104.json create mode 100644 packages/security_detection_engine/kibana/security_rule/b347b919-665f-4aac-b9e8-68369bf2340c_104.json create mode 100644 packages/security_detection_engine/kibana/security_rule/b66b7e2b-d50a-49b9-a6fc-3a383baedc6b_1.json create mode 100644 packages/security_detection_engine/kibana/security_rule/ba342eb2-583c-439f-b04d-1fdd7c1417cc_104.json create mode 100644 packages/security_detection_engine/kibana/security_rule/c28c4d8c-f014-40ef-88b6-79a1d67cd499_104.json create mode 100644 packages/security_detection_engine/kibana/security_rule/c7db5533-ca2a-41f6-a8b0-ee98abe0f573_105.json create mode 100644 packages/security_detection_engine/kibana/security_rule/cd66a419-9b3f-4f57-8ff8-ac4cd2d5f530_104.json create mode 100644 packages/security_detection_engine/kibana/security_rule/d4af3a06-1e0a-48ec-b96a-faf2309fae46_104.json create mode 100644 packages/security_detection_engine/kibana/security_rule/d4b73fa0-9d43-465e-b8bf-50230da6718b_104.json create mode 100644 packages/security_detection_engine/kibana/security_rule/d7d5c059-c19a-4a96-8ae3-41496ef3bcf9_104.json create mode 100644 packages/security_detection_engine/kibana/security_rule/d93e61db-82d6-4095-99aa-714988118064_1.json create mode 100644 packages/security_detection_engine/kibana/security_rule/dca28dee-c999-400f-b640-50a081cc0fd1_209.json create mode 100644 packages/security_detection_engine/kibana/security_rule/df197323-72a8-46a9-a08e-3f5b04a4a97a_104.json create mode 100644 packages/security_detection_engine/kibana/security_rule/e26aed74-c816-40d3-a810-48d6fbd8b2fd_105.json create mode 100644 packages/security_detection_engine/kibana/security_rule/eaa77d63-9679-4ce3-be25-3ba8b795e5fa_104.json create mode 100644 packages/security_detection_engine/kibana/security_rule/f3e22c8b-ea47-45d1-b502-b57b6de950b3_7.json create mode 100644 packages/security_detection_engine/kibana/security_rule/f9590f47-6bd5-4a49-bd49-a2f886476fb9_105.json diff --git a/packages/security_detection_engine/changelog.yml b/packages/security_detection_engine/changelog.yml index 930b4af4558..b4a6d8f8dad 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: 8.14.4-beta.1 + changes: + - description: Release security rules update + type: enhancement + link: https://github.com/elastic/integrations/pulls/0000 - version: 8.14.3 changes: - description: Release security rules update diff --git a/packages/security_detection_engine/kibana/security_rule/0b29cab4-dbbd-4a3f-9e8e-1287c7c11ae5_106.json b/packages/security_detection_engine/kibana/security_rule/0b29cab4-dbbd-4a3f-9e8e-1287c7c11ae5_106.json new file mode 100644 index 00000000000..a585b9fbcc4 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/0b29cab4-dbbd-4a3f-9e8e-1287c7c11ae5_106.json @@ -0,0 +1,67 @@ +{ + "attributes": { + "anomaly_threshold": 50, + "author": [ + "Elastic" + ], + "description": "Identifies unusual parent-child process relationships that can indicate malware execution or persistence mechanisms. Malicious scripts often call on other applications and processes as part of their exploit payload. For example, when a malicious Office document runs scripts as part of an exploit payload, Excel or Word may start a script interpreter process, which, in turn, runs a script that downloads and executes malware. Another common scenario is Outlook running an unusual process when malware is downloaded in an email. Monitoring and identifying anomalous process relationships is a method of detecting new and emerging malware that is not yet recognized by anti-virus scanners.", + "false_positives": [ + "Users running scripts in the course of technical support operations of software upgrades could trigger this alert. A newly installed program or one that runs rarely as part of a monthly or quarterly workflow could trigger this alert." + ], + "from": "now-45m", + "interval": "15m", + "license": "Elastic License v2", + "machine_learning_job_id": [ + "v3_windows_anomalous_process_creation" + ], + "name": "Anomalous Windows Process Creation", + "note": "## Triage and analysis\n\n### Investigating Anomalous Windows Process Creation\n\nSearching for abnormal Windows processes is a good methodology to find potentially malicious activity within a network. Understanding what is commonly run within an environment and developing baselines for legitimate activity can help uncover potential malware and suspicious behaviors.\n\nThis rule uses a machine learning job to detect an anomalous Windows process with an unusual parent-child relationship, which could indicate malware execution or persistence activities on the host machine.\n\n> **Note**:\n> This investigation guide uses the [Osquery Markdown Plugin](https://www.elastic.co/guide/en/security/master/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 - If the parent process is a legitimate system utility or service, this could be related to software updates or system management. If the parent process is something user-facing like an Office application, this process could be more suspicious.\n - Investigate the process metadata \u2014 such as the digital signature, directory, etc. \u2014 to obtain more context that can indicate whether the executable is associated with an expected software vendor or package.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Consider the user as identified by the `user.name` field. Is this program part of an expected workflow for the user who ran this program on this host?\n- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations.\n- Validate if the activity has a consistent cadence (for example, if it runs monthly or quarterly), as it could be part of a monthly or quarterly business process.\n- Examine the arguments and working directory of the process. These may provide indications as to the source of the program or the nature of the tasks it is performing.\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\":\"Retrieve Service Unisgned 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- 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- 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- Unusual Process For a Windows Host - 6d448b96-c922-4adb-b51c-b767f1ea5b76\n- Unusual Windows Path Activity - 445a342e-03fb-42d0-8656-0367eb2dead5\n- Unusual Windows Process Calling the Metadata Service - abae61a8-c560-4dbd-acca-1e1438bff36b\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- 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", + "references": [ + "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "windows", + "version": "^1.5.0" + } + ], + "risk_score": 21, + "rule_id": "0b29cab4-dbbd-4a3f-9e8e-1287c7c11ae5", + "setup": "## Setup\n\nThis rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:\n- Elastic Defend\n- Windows\n\n### Anomaly Detection Setup\n\nOnce the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the \"Definition\" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).\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 to your 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/current/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\n### Windows Integration Setup\nThe Windows integration allows you to monitor the Windows OS, services, applications, and more.\n\n#### The following steps should be executed in order to add the Elastic Agent System integration \"windows\" to your system:\n- Go to the Kibana home page and click \u201cAdd integrations\u201d.\n- In the query bar, search for \u201cWindows\u201d and select the integration to see more details about it.\n- Click \u201cAdd Windows\u201d.\n- Configure the integration name and optionally add a description.\n- Review optional and advanced settings accordingly.\n- Add the newly installed \u201cwindows\u201d to an existing or a new agent policy, and deploy the agent on your system from which windows log files are desirable.\n- Click \u201cSave and Continue\u201d.\n- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/windows).\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Rule Type: ML", + "Rule Type: Machine Learning", + "Tactic: Persistence", + "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/" + } + ] + } + ], + "type": "machine_learning", + "version": 106 + }, + "id": "0b29cab4-dbbd-4a3f-9e8e-1287c7c11ae5_106", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/0c41e478-5263-4c69-8f9e-7dfd2c22da64_7.json b/packages/security_detection_engine/kibana/security_rule/0c41e478-5263-4c69-8f9e-7dfd2c22da64_7.json new file mode 100644 index 00000000000..c7acf5e1e74 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/0c41e478-5263-4c69-8f9e-7dfd2c22da64_7.json @@ -0,0 +1,142 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule is triggered when an IP address indicator from the Threat Intel Filebeat module or integrations has a match against a network event.", + "from": "now-65m", + "index": [ + "auditbeat-*", + "endgame-*", + "filebeat-*", + "logs-*", + "packetbeat-*", + "winlogbeat-*" + ], + "interval": "1h", + "language": "kuery", + "license": "Elastic License v2", + "name": "Threat Intel IP Address Indicator Match", + "note": "## Triage and Analysis\n\n### Investigating Threat Intel IP Address Indicator Match\n\nThreat Intel indicator match rules allow matching from a local observation, such as an endpoint event that records a file hash with an entry of a file hash stored within the Threat Intel integrations index.\n\nMatches are based on threat intelligence data that's been ingested during the last 30 days. Some integrations don't place expiration dates on their threat indicators, so we strongly recommend validating ingested threat indicators and reviewing match results. When reviewing match results, check associated activity to determine whether the event requires additional investigation.\n\nThis rule is triggered when an IP address indicator from the Threat Intel Filebeat module or a threat intelligence integration matches against a network event.\n\n> **Note**:\n> This investigation guide uses the [Osquery Markdown Plugin](https://www.elastic.co/guide/en/security/master/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- Gain context about the field that matched the local observation so you can understand the nature of the connection. This information can be found in the `threat.indicator.matched.field` field.\n- Investigate the IP address, which can be found in the `threat.indicator.matched.atomic` field:\n - Check the reputation of the IP address in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.\n - Execute a reverse DNS lookup to retrieve hostnames associated with the given IP address.\n- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts.\n- Identify the process responsible for the connection, and 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- Retrieve the involved process executable and 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- Using the data collected through the analysis, scope users targeted and other machines infected in the environment.\n\n### False Positive Analysis\n\n- When a match is found, it's important to consider the indicator's initial release date. Threat intelligence is useful for augmenting existing security processes but can quickly become outdated. In other words, some threat intelligence only represents a specific set of activity observed at a specific time. For example, an IP address may have hosted malware observed in a Dridex campaign months ago, but it's possible that IP has been remediated and no longer represents any threat.\n- False positives might occur after large and publicly written campaigns if curious employees interact with attacker infrastructure.\n- Some feeds may include internal or known benign addresses by mistake (e.g., 8.8.8.8, google.com, 127.0.0.1, etc.). Make sure you understand how blocking a specific domain or address might impact the organization or normal system functioning.\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": "source.ip:* or destination.ip:*\n", + "references": [ + "https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-threatintel.html", + "https://www.elastic.co/guide/en/security/master/es-threat-intel-integrations.html", + "https://www.elastic.co/security/tip" + ], + "required_fields": [ + { + "ecs": true, + "name": "destination.ip", + "type": "ip" + }, + { + "ecs": true, + "name": "source.ip", + "type": "ip" + } + ], + "risk_score": 99, + "rule_id": "0c41e478-5263-4c69-8f9e-7dfd2c22da64", + "setup": "## Setup\n\nThis rule needs threat intelligence indicators to work.\nThreat intelligence indicators can be collected using an [Elastic Agent integration](https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html#agent-ti-integration),\nthe [Threat Intel module](https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html#ti-mod-integration),\nor a [custom integration](https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html#custom-ti-integration).\n\nMore information can be found [here](https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html).\n", + "severity": "critical", + "tags": [ + "OS: Windows", + "Data Source: Elastic Endgame", + "Rule Type: Threat Match" + ], + "threat_filters": [ + { + "$state": { + "store": "appState" + }, + "meta": { + "disabled": false, + "key": "event.category", + "negate": false, + "params": { + "query": "threat" + }, + "type": "phrase" + }, + "query": { + "match_phrase": { + "event.category": "threat" + } + } + }, + { + "$state": { + "store": "appState" + }, + "meta": { + "disabled": false, + "key": "event.kind", + "negate": false, + "params": { + "query": "enrichment" + }, + "type": "phrase" + }, + "query": { + "match_phrase": { + "event.kind": "enrichment" + } + } + }, + { + "$state": { + "store": "appState" + }, + "meta": { + "disabled": false, + "key": "event.type", + "negate": false, + "params": { + "query": "indicator" + }, + "type": "phrase" + }, + "query": { + "match_phrase": { + "event.type": "indicator" + } + } + } + ], + "threat_index": [ + "filebeat-*", + "logs-ti_*" + ], + "threat_indicator_path": "threat.indicator", + "threat_language": "kuery", + "threat_mapping": [ + { + "entries": [ + { + "field": "source.ip", + "type": "mapping", + "value": "threat.indicator.ip" + } + ] + }, + { + "entries": [ + { + "field": "destination.ip", + "type": "mapping", + "value": "threat.indicator.ip" + } + ] + } + ], + "threat_query": "@timestamp >= \"now-30d/d\" and event.module:(threatintel or ti_*) and threat.indicator.ip:* and not labels.is_ioc_transform_source:\"true\"", + "timeline_id": "495ad7a7-316e-4544-8a0f-9c098daee76e", + "timeline_title": "Generic Threat Match Timeline", + "timestamp_override": "event.ingested", + "type": "threat_match", + "version": 7 + }, + "id": "0c41e478-5263-4c69-8f9e-7dfd2c22da64_7", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/138c5dd5-838b-446e-b1ac-c995c7f8108a_105.json b/packages/security_detection_engine/kibana/security_rule/138c5dd5-838b-446e-b1ac-c995c7f8108a_105.json new file mode 100644 index 00000000000..35276222da4 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/138c5dd5-838b-446e-b1ac-c995c7f8108a_105.json @@ -0,0 +1,80 @@ +{ + "attributes": { + "anomaly_threshold": 75, + "author": [ + "Elastic" + ], + "description": "A machine learning job found an unusual user name in the authentication logs. An unusual user name is one way of detecting credentialed access by means of a new or dormant user account. An inactive user account (because the user has left the organization) that becomes active may be due to credentialed access using a compromised account password. Threat actors will sometimes also create new users as a means of persisting in a compromised web application.", + "false_positives": [ + "User accounts that are rarely active, such as a site reliability engineer (SRE) or developer logging into a production server for troubleshooting, may trigger this alert. Under some conditions, a newly created user account may briefly trigger this alert while the model is learning." + ], + "from": "now-30m", + "interval": "15m", + "license": "Elastic License v2", + "machine_learning_job_id": "auth_rare_user", + "name": "Rare User Logon", + "note": "## Triage and analysis\n\n### Investigating Rare User Logon\n\nThis rule uses a machine learning job to detect an unusual user name in authentication logs, which could detect new accounts created for persistence.\n\n#### Possible investigation steps\n\n- Check if the user was newly created and if the company policies were followed.\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 involved users during the past 48 hours.\n- Investigate any abnormal account behavior, such as command executions, file creations or modifications, and network connections.\n\n### False positive analysis\n\n- Accounts that are used for specific purposes \u2014 and therefore not normally active \u2014 may trigger the alert.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the 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- 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", + "references": [ + "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html" + ], + "related_integrations": [ + { + "package": "auditd_manager", + "version": "^1.0.0" + }, + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "system", + "version": "^1.6.4" + } + ], + "risk_score": 21, + "rule_id": "138c5dd5-838b-446e-b1ac-c995c7f8108a", + "setup": "## Setup\n\nThis rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:\n- Elastic Defend\n- Auditd Manager\n- System\n\n### Anomaly Detection Setup\n\nOnce the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the \"Definition\" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).\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 to your 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/current/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\n### Auditd Manager Integration Setup\nThe Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel.\nAuditd Manager 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.\n\n#### The following steps should be executed in order to add the Elastic Agent System integration \"auditd_manager\" to your system:\n- Go to the Kibana home page and click \u201cAdd integrations\u201d.\n- In the query bar, search for \u201cAuditd Manager\u201d and select the integration to see more details about it.\n- Click \u201cAdd Auditd Manager\u201d.\n- Configure the integration name and optionally add a description.\n- Review optional and advanced settings accordingly.\n- Add the newly installed \u201cauditd manager\u201d to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable.\n- Click \u201cSave and Continue\u201d.\n- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/auditd_manager).\n\n#### Rule Specific Setup Note\nAuditd Manager subscribes to the kernel and receives events as they occur without any additional configuration.\nHowever, 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.\n- For this detection rule no additional audit rules are required.\n\n### System Integration Setup\nThe System integration allows you to collect system logs and metrics from your servers with Elastic Agent.\n\n#### The following steps should be executed in order to add the Elastic Agent System integration \"system\" to your system:\n- Go to the Kibana home page and click \u201cAdd integrations\u201d.\n- In the query bar, search for \u201cSystem\u201d and select the integration to see more details about it.\n- Click \u201cAdd System\u201d.\n- Configure the integration name and optionally add a description.\n- Review optional and advanced settings accordingly.\n- Add the newly installed \u201csystem\u201d to an existing or a new agent policy, and deploy the agent on your system from which system log files are desirable.\n- Click \u201cSave and Continue\u201d.\n- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/system).\n", + "severity": "low", + "tags": [ + "Use Case: Identity and Access Audit", + "Use Case: Threat Detection", + "Rule Type: ML", + "Rule Type: Machine Learning", + "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.002", + "name": "Domain Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/002/" + }, + { + "id": "T1078.003", + "name": "Local Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/003/" + } + ] + } + ] + } + ], + "type": "machine_learning", + "version": 105 + }, + "id": "138c5dd5-838b-446e-b1ac-c995c7f8108a_105", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/1781d055-5c66-4adf-9c59-fc0fa58336a5_105.json b/packages/security_detection_engine/kibana/security_rule/1781d055-5c66-4adf-9c59-fc0fa58336a5_105.json new file mode 100644 index 00000000000..e02c6a7becb --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/1781d055-5c66-4adf-9c59-fc0fa58336a5_105.json @@ -0,0 +1,78 @@ +{ + "attributes": { + "anomaly_threshold": 50, + "author": [ + "Elastic" + ], + "description": "A machine learning job detected activity for a username that is not normally active, which can indicate unauthorized changes, activity by unauthorized users, lateral movement, or compromised credentials. In many organizations, new usernames are not often created apart from specific types of system activities, such as creating new accounts for new employees. These user accounts quickly become active and routine. Events from rarely used usernames can point to suspicious activity. Additionally, automated Linux fleets tend to see activity from rarely used usernames only when personnel log in to make authorized or unauthorized changes, or threat actors have acquired credentials and log in for malicious purposes. Unusual usernames can also indicate pivoting, where compromised credentials are used to try and move laterally from one host to another.", + "false_positives": [ + "Uncommon user activity can be due to an administrator or help desk technician logging onto a workstation or server in order to perform manual troubleshooting or reconfiguration." + ], + "from": "now-45m", + "interval": "15m", + "license": "Elastic License v2", + "machine_learning_job_id": [ + "v3_windows_anomalous_user_name" + ], + "name": "Unusual Windows Username", + "note": "## Triage and analysis\n\n### Investigating an Unusual Windows User\nDetection alerts from this rule indicate activity for a Windows user name that is rare and unusual. Here are some possible avenues of investigation:\n- Consider the user as identified by the username field. Is this program part of an expected workflow for the user who ran this program on this host? Could this be related to occasional troubleshooting or support activity?\n- Examine the history of user activity. If this user only manifested recently, it might be a service account for a new software package. If it has a consistent cadence (for example if it runs monthly or quarterly), it might be part of a monthly or quarterly business process.\n- Examine the process arguments, title and working directory. These may provide indications as to the source of the program or the nature of the tasks that the user is performing.\n- Consider the same for the parent process. If the parent process is a legitimate system utility or service, this could be related to software updates or system management. If the parent process is something user-facing like an Office application, this process could be more suspicious.", + "references": [ + "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "windows", + "version": "^1.5.0" + } + ], + "risk_score": 21, + "rule_id": "1781d055-5c66-4adf-9c59-fc0fa58336a5", + "setup": "## Setup\n\nThis rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:\n- Elastic Defend\n- Windows\n\n### Anomaly Detection Setup\n\nOnce the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the \"Definition\" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).\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 to your 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/current/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\n### Windows Integration Setup\nThe Windows integration allows you to monitor the Windows OS, services, applications, and more.\n\n#### The following steps should be executed in order to add the Elastic Agent System integration \"windows\" to your system:\n- Go to the Kibana home page and click \u201cAdd integrations\u201d.\n- In the query bar, search for \u201cWindows\u201d and select the integration to see more details about it.\n- Click \u201cAdd Windows\u201d.\n- Configure the integration name and optionally add a description.\n- Review optional and advanced settings accordingly.\n- Add the newly installed \u201cwindows\u201d to an existing or a new agent policy, and deploy the agent on your system from which windows log files are desirable.\n- Click \u201cSave and Continue\u201d.\n- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/windows).\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Rule Type: ML", + "Rule Type: Machine Learning", + "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.002", + "name": "Domain Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/002/" + }, + { + "id": "T1078.003", + "name": "Local Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/003/" + } + ] + } + ] + } + ], + "type": "machine_learning", + "version": 105 + }, + "id": "1781d055-5c66-4adf-9c59-fc0fa58336a5_105", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/1781d055-5c66-4adf-9c71-fc0fa58338c7_104.json b/packages/security_detection_engine/kibana/security_rule/1781d055-5c66-4adf-9c71-fc0fa58338c7_104.json new file mode 100644 index 00000000000..096b020c7c6 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/1781d055-5c66-4adf-9c71-fc0fa58338c7_104.json @@ -0,0 +1,72 @@ +{ + "attributes": { + "anomaly_threshold": 50, + "author": [ + "Elastic" + ], + "description": "A machine learning job detected an unusual Windows service, This can indicate execution of unauthorized services, malware, or persistence mechanisms. In corporate Windows environments, hosts do not generally run many rare or unique services. This job helps detect malware and persistence mechanisms that have been installed and run as a service.", + "false_positives": [ + "A newly installed program or one that runs rarely as part of a monthly or quarterly workflow could trigger this alert." + ], + "from": "now-45m", + "interval": "15m", + "license": "Elastic License v2", + "machine_learning_job_id": [ + "v3_windows_anomalous_service" + ], + "name": "Unusual Windows Service", + "references": [ + "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "windows", + "version": "^1.5.0" + } + ], + "risk_score": 21, + "rule_id": "1781d055-5c66-4adf-9c71-fc0fa58338c7", + "setup": "## Setup\n\nThis rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:\n- Elastic Defend\n- Windows\n\n### Anomaly Detection Setup\n\nOnce the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the \"Definition\" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).\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 to your 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/current/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\n### Windows Integration Setup\nThe Windows integration allows you to monitor the Windows OS, services, applications, and more.\n\n#### The following steps should be executed in order to add the Elastic Agent System integration \"windows\" to your system:\n- Go to the Kibana home page and click \u201cAdd integrations\u201d.\n- In the query bar, search for \u201cWindows\u201d and select the integration to see more details about it.\n- Click \u201cAdd Windows\u201d.\n- Configure the integration name and optionally add a description.\n- Review optional and advanced settings accordingly.\n- Add the newly installed \u201cwindows\u201d to an existing or a new agent policy, and deploy the agent on your system from which windows log files are desirable.\n- Click \u201cSave and Continue\u201d.\n- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/windows).\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Rule Type: ML", + "Rule Type: Machine Learning", + "Tactic: Persistence" + ], + "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/" + } + ] + } + ] + } + ], + "type": "machine_learning", + "version": 104 + }, + "id": "1781d055-5c66-4adf-9c71-fc0fa58338c7_104", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/1781d055-5c66-4adf-9d60-fc0fa58337b6_105.json b/packages/security_detection_engine/kibana/security_rule/1781d055-5c66-4adf-9d60-fc0fa58337b6_105.json new file mode 100644 index 00000000000..8a365d49c80 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/1781d055-5c66-4adf-9d60-fc0fa58337b6_105.json @@ -0,0 +1,73 @@ +{ + "attributes": { + "anomaly_threshold": 50, + "author": [ + "Elastic" + ], + "description": "A machine learning job detected a PowerShell script with unusual data characteristics, such as obfuscation, that may be a characteristic of malicious PowerShell script text blocks.", + "false_positives": [ + "Certain kinds of security testing may trigger this alert. PowerShell scripts that use high levels of obfuscation or have unusual script block payloads may trigger this alert." + ], + "from": "now-45m", + "interval": "15m", + "license": "Elastic License v2", + "machine_learning_job_id": [ + "v3_windows_anomalous_script" + ], + "name": "Suspicious Powershell Script", + "references": [ + "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html", + "https://www.elastic.co/security-labs/detecting-living-off-the-land-attacks-with-new-elastic-integration" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "windows", + "version": "^1.5.0" + } + ], + "risk_score": 21, + "rule_id": "1781d055-5c66-4adf-9d60-fc0fa58337b6", + "setup": "## Setup\n\nThis rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:\n- Elastic Defend\n- Windows\n\n### Anomaly Detection Setup\n\nOnce the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the \"Definition\" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).\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 to your 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/current/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\n### Windows Integration Setup\nThe Windows integration allows you to monitor the Windows OS, services, applications, and more.\n\n#### The following steps should be executed in order to add the Elastic Agent System integration \"windows\" to your system:\n- Go to the Kibana home page and click \u201cAdd integrations\u201d.\n- In the query bar, search for \u201cWindows\u201d and select the integration to see more details about it.\n- Click \u201cAdd Windows\u201d.\n- Configure the integration name and optionally add a description.\n- Review optional and advanced settings accordingly.\n- Add the newly installed \u201cwindows\u201d to an existing or a new agent policy, and deploy the agent on your system from which windows log files are desirable.\n- Click \u201cSave and Continue\u201d.\n- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/windows).\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Rule Type: ML", + "Rule Type: Machine Learning", + "Tactic: Execution" + ], + "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/" + } + ] + } + ] + } + ], + "type": "machine_learning", + "version": 105 + }, + "id": "1781d055-5c66-4adf-9d60-fc0fa58337b6_105", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/1781d055-5c66-4adf-9d82-fc0fa58449c8_104.json b/packages/security_detection_engine/kibana/security_rule/1781d055-5c66-4adf-9d82-fc0fa58449c8_104.json new file mode 100644 index 00000000000..1d5fbd713f1 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/1781d055-5c66-4adf-9d82-fc0fa58449c8_104.json @@ -0,0 +1,59 @@ +{ + "attributes": { + "anomaly_threshold": 50, + "author": [ + "Elastic" + ], + "description": "A machine learning job detected an unusual user context switch, using the runas command or similar techniques, which can indicate account takeover or privilege escalation using compromised accounts. Privilege elevation using tools like runas are more commonly used by domain and network administrators than by regular Windows users.", + "false_positives": [ + "Uncommon user privilege elevation activity can be due to an administrator, help desk technician, or a user performing manual troubleshooting or reconfiguration." + ], + "from": "now-45m", + "interval": "15m", + "license": "Elastic License v2", + "machine_learning_job_id": [ + "v3_windows_rare_user_runas_event" + ], + "name": "Unusual Windows User Privilege Elevation Activity", + "references": [ + "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "windows", + "version": "^1.5.0" + } + ], + "risk_score": 21, + "rule_id": "1781d055-5c66-4adf-9d82-fc0fa58449c8", + "setup": "## Setup\n\nThis rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:\n- Elastic Defend\n- Windows\n\n### Anomaly Detection Setup\n\nOnce the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the \"Definition\" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).\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 to your 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/current/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\n### Windows Integration Setup\nThe Windows integration allows you to monitor the Windows OS, services, applications, and more.\n\n#### The following steps should be executed in order to add the Elastic Agent System integration \"windows\" to your system:\n- Go to the Kibana home page and click \u201cAdd integrations\u201d.\n- In the query bar, search for \u201cWindows\u201d and select the integration to see more details about it.\n- Click \u201cAdd Windows\u201d.\n- Configure the integration name and optionally add a description.\n- Review optional and advanced settings accordingly.\n- Add the newly installed \u201cwindows\u201d to an existing or a new agent policy, and deploy the agent on your system from which windows log files are desirable.\n- Click \u201cSave and Continue\u201d.\n- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/windows).\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Rule Type: ML", + "Rule Type: Machine Learning", + "Tactic: Privilege Escalation" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0004", + "name": "Privilege Escalation", + "reference": "https://attack.mitre.org/tactics/TA0004/" + }, + "technique": [] + } + ], + "type": "machine_learning", + "version": 104 + }, + "id": "1781d055-5c66-4adf-9d82-fc0fa58449c8_104", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/1781d055-5c66-4adf-9e93-fc0fa69550c9_104.json b/packages/security_detection_engine/kibana/security_rule/1781d055-5c66-4adf-9e93-fc0fa69550c9_104.json new file mode 100644 index 00000000000..48d5d54d8dc --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/1781d055-5c66-4adf-9e93-fc0fa69550c9_104.json @@ -0,0 +1,66 @@ +{ + "attributes": { + "anomaly_threshold": 50, + "author": [ + "Elastic" + ], + "description": "A machine learning job detected an unusual remote desktop protocol (RDP) username, which can indicate account takeover or credentialed persistence using compromised accounts. RDP attacks, such as BlueKeep, also tend to use unusual usernames.", + "false_positives": [ + "Uncommon username activity can be due to an engineer logging onto a server instance in order to perform manual troubleshooting or reconfiguration." + ], + "from": "now-45m", + "interval": "15m", + "license": "Elastic License v2", + "machine_learning_job_id": [ + "v3_windows_rare_user_type10_remote_login" + ], + "name": "Unusual Windows Remote User", + "note": "## Triage and analysis\n\n### Investigating an Unusual Windows User\nDetection alerts from this rule indicate activity for a rare and unusual Windows RDP (remote desktop) user. Here are some possible avenues of investigation:\n- Consider the user as identified by the username field. Is the user part of a group who normally logs into Windows hosts using RDP (remote desktop protocol)? Is this logon activity part of an expected workflow for the user?\n- Consider the source of the login. If the source is remote, could this be related to occasional troubleshooting or support activity by a vendor or an employee working remotely?", + "references": [ + "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "windows", + "version": "^1.5.0" + } + ], + "risk_score": 21, + "rule_id": "1781d055-5c66-4adf-9e93-fc0fa69550c9", + "setup": "## Setup\n\nThis rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:\n- Elastic Defend\n- Windows\n\n### Anomaly Detection Setup\n\nOnce the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the \"Definition\" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).\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 to your 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/current/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\n### Windows Integration Setup\nThe Windows integration allows you to monitor the Windows OS, services, applications, and more.\n\n#### The following steps should be executed in order to add the Elastic Agent System integration \"windows\" to your system:\n- Go to the Kibana home page and click \u201cAdd integrations\u201d.\n- In the query bar, search for \u201cWindows\u201d and select the integration to see more details about it.\n- Click \u201cAdd Windows\u201d.\n- Configure the integration name and optionally add a description.\n- Review optional and advanced settings accordingly.\n- Add the newly installed \u201cwindows\u201d to an existing or a new agent policy, and deploy the agent on your system from which windows log files are desirable.\n- Click \u201cSave and Continue\u201d.\n- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/windows).\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Rule Type: ML", + "Rule Type: Machine Learning", + "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/" + } + ] + } + ], + "type": "machine_learning", + "version": 104 + }, + "id": "1781d055-5c66-4adf-9e93-fc0fa69550c9_104", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/17e68559-b274-4948-ad0b-f8415bb31126_104.json b/packages/security_detection_engine/kibana/security_rule/17e68559-b274-4948-ad0b-f8415bb31126_104.json new file mode 100644 index 00000000000..61fa6ac6256 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/17e68559-b274-4948-ad0b-f8415bb31126_104.json @@ -0,0 +1,43 @@ +{ + "attributes": { + "anomaly_threshold": 50, + "author": [ + "Elastic" + ], + "description": "A machine learning job detected an unusual network destination domain name. This can be due to initial access, persistence, command-and-control, or exfiltration activity. For example, when a user clicks on a link in a phishing email or opens a malicious document, a request may be sent to download and run a payload from an uncommon web server name. When malware is already running, it may send requests to an uncommon DNS domain the malware uses for command-and-control communication.", + "false_positives": [ + "Web activity that occurs rarely in small quantities can trigger this alert. Possible examples are browsing technical support or vendor URLs that are used very sparsely. A user who visits a new and unique web destination may trigger this alert when the activity is sparse. Web applications that generate URLs unique to a transaction may trigger this when they are used sparsely. Web domains can be excluded in cases such as these." + ], + "from": "now-45m", + "interval": "15m", + "license": "Elastic License v2", + "machine_learning_job_id": "packetbeat_rare_server_domain", + "name": "Unusual Network Destination Domain Name", + "references": [ + "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html" + ], + "related_integrations": [ + { + "package": "auditd_manager", + "version": "^1.0.0" + }, + { + "package": "endpoint", + "version": "^8.2.0" + } + ], + "risk_score": 21, + "rule_id": "17e68559-b274-4948-ad0b-f8415bb31126", + "setup": "## Setup\n\nThis rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:\n- Elastic Defend\n- Auditd Manager\n\n### Anomaly Detection Setup\n\nOnce the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the \"Definition\" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).\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 to your 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/current/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\n### Auditd Manager Integration Setup\nThe Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel.\nAuditd Manager 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.\n\n#### The following steps should be executed in order to add the Elastic Agent System integration \"auditd_manager\" to your system:\n- Go to the Kibana home page and click \u201cAdd integrations\u201d.\n- In the query bar, search for \u201cAuditd Manager\u201d and select the integration to see more details about it.\n- Click \u201cAdd Auditd Manager\u201d.\n- Configure the integration name and optionally add a description.\n- Review optional and advanced settings accordingly.\n- Add the newly installed \u201cauditd manager\u201d to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable.\n- Click \u201cSave and Continue\u201d.\n- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/auditd_manager).\n\n#### Rule Specific Setup Note\nAuditd Manager subscribes to the kernel and receives events as they occur without any additional configuration.\nHowever, 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.\n- For this detection rule no additional audit rules are required.\n", + "severity": "low", + "tags": [ + "Use Case: Threat Detection", + "Rule Type: ML", + "Rule Type: Machine Learning" + ], + "type": "machine_learning", + "version": 104 + }, + "id": "17e68559-b274-4948-ad0b-f8415bb31126_104", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/192657ba-ab0e-4901-89a2-911d611eee98_2.json b/packages/security_detection_engine/kibana/security_rule/192657ba-ab0e-4901-89a2-911d611eee98_2.json new file mode 100644 index 00000000000..f49a7251f26 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/192657ba-ab0e-4901-89a2-911d611eee98_2.json @@ -0,0 +1,166 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule leverages the File Integrity Monitoring (FIM) integration to detect file modifications of files that are commonly used for persistence on Linux systems. The rule detects modifications to files that are commonly used for cron jobs, systemd services, message-of-the-day (MOTD), SSH configurations, shell configurations, runtime control, init daemon, passwd/sudoers/shadow files, Systemd udevd, and XDG/KDE autostart entries. To leverage this rule, the paths specified in the query need to be added to the FIM policy in the Elastic Security app.", + "from": "now-9m", + "index": [ + "logs-fim.event-*", + "auditbeat-*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Potential Persistence via File Modification", + "query": "file where host.os.type == \"linux\" and event.dataset == \"fim.event\" and event.action == \"updated\" and\nfile.path : (\n // cron, anacron & at\n \"/etc/cron.d/*\", \"/etc/cron.daily/*\", \"/etc/cron.hourly/*\", \"/etc/cron.monthly/*\",\n \"/etc/cron.weekly/*\", \"/etc/crontab\", \"/var/spool/cron/crontabs/*\", \"/etc/cron.allow\",\n \"/etc/cron.deny\", \"/var/spool/anacron/*\", \"/var/spool/cron/atjobs/*\",\n\n // systemd services & timers\n \"/etc/systemd/system/*\", \"/usr/local/lib/systemd/system/*\", \"/lib/systemd/system/*\",\n \"/usr/lib/systemd/system/*\", \"/home/*/.config/systemd/user/*\", \"/home/*/.local/share/systemd/user/*\",\n \"/root/.config/systemd/user/*\", \"/root/.local/share/systemd/user/*\",\n\n // LD_PRELOAD\n \"/etc/ld.so.preload\", \"/etc/ld.so.conf.d/*\", \"/etc/ld.so.conf\",\n\n // message-of-the-day (MOTD)\n \"/etc/update-motd.d/*\",\n\n // SSH\n \"/home/*/.ssh/*\", \"/root/.ssh/*\", \"/etc/ssh/*\",\n\n // system-wide shell configurations\n \"/etc/profile\", \"/etc/profile.d/*\", \"/etc/bash.bashrc\", \"/etc/zsh/*\", \"/etc/csh.cshrc\",\n \"/etc/csh.login\", \"/etc/fish/config.fish\", \"/etc/ksh.kshrc\",\n\n // root and user shell configurations\n \"/home/*/.profile\", \"/home/*/.bashrc\", \"/home/*/.bash_login\", \"/home/*/.bash_logout\",\n \"/root/.profile\", \"/root/.bashrc\", \"/root/.bash_login\", \"/root/.bash_logout\",\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\n // runtime control\n \"/etc/rc.common\", \"/etc/rc.local\",\n\n // init daemon\n \"/etc/init.d/*\",\n\n // passwd/sudoers/shadow\n \"/etc/passwd\", \"/etc/shadow\", \"/etc/sudoers\", \"/etc/sudoers.d/*\",\n\n // Systemd udevd\n \"/lib/udev/*\", \"/etc/udev/rules.d/*\", \"/usr/lib/udev/rules.d/*\", \"/run/udev/rules.d/*\",\n\n // XDG/KDE autostart entries\n \"/home/*/.config/autostart/*\", \"/root/.config/autostart/*\", \"/etc/xdg/autostart/*\", \"/usr/share/autostart/*\",\n \"/home/*/.kde/Autostart/*\", \"/root/.kde/Autostart/*\",\n \"/home/*/.kde4/Autostart/*\", \"/root/.kde4/Autostart/*\",\n \"/home/*/.kde/share/autostart/*\", \"/root/.kde/share/autostart/*\",\n \"/home/*/.kde4/share/autostart/*\", \"/root/.kde4/share/autostart/*\",\n \"/home/*/.local/share/autostart/*\", \"/root/.local/share/autostart/*\",\n \"/home/*/.config/autostart-scripts/*\", \"/root/.config/autostart-scripts/*\"\n) and not (\n file.path : (\n \"/var/spool/cron/crontabs/tmp.*\", \"/run/udev/rules.d/*rules.*\", \"/home/*/.ssh/known_hosts.*\", \"/root/.ssh/known_hosts.*\"\n ) or\n file.extension in (\"dpkg-new\", \"dpkg-remove\", \"SEQ\")\n)\n", + "related_integrations": [ + { + "package": "fim", + "version": "^1.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.dataset", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.extension", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.path", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + } + ], + "risk_score": 21, + "rule_id": "192657ba-ab0e-4901-89a2-911d611eee98", + "setup": "## Setup\n\nThis rule requires data coming in from the Elastic File Integrity Monitoring (FIM) integration.\n\n### Elastic FIM Integration Setup\nTo configure the Elastic FIM integration, follow these steps:\n\n1. Install and configure the Elastic Agent on your Linux system. You can refer to the [Elastic Agent documentation](https://www.elastic.co/guide/en/fleet/current/elastic-agent-installation.html) for detailed instructions.\n2. Once the Elastic Agent is installed, navigate to the Elastic Security app in Kibana.\n3. In the Kibana home page, click on \"Integrations\" in the left sidebar.\n4. Search for \"File Integrity Monitoring\" in the search bar and select the integration.\n5. Provide a name and optional description for the integration.\n6. Select the appropriate agent policy for your Linux system or create a new one.\n7. Configure the FIM policy by specifying the paths that you want to monitor for file modifications. You can use the same paths mentioned in the `query` field of the rule. Note that FIM does not accept wildcards in the paths, so you need to specify the exact paths you want to monitor.\n8. Save the configuration and the Elastic Agent will start monitoring the specified paths for file modifications.\n\nFor more details on configuring the Elastic FIM integration, you can refer to the [Elastic FIM documentation](https://docs.elastic.co/integrations/fim).\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Persistence", + "Tactic: Privilege Escalation", + "Data Source: File Integrity Monitoring" + ], + "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": "T1556", + "name": "Modify Authentication Process", + "reference": "https://attack.mitre.org/techniques/T1556/" + }, + { + "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/" + } + ] + }, + { + "id": "T1136", + "name": "Create Account", + "reference": "https://attack.mitre.org/techniques/T1136/", + "subtechnique": [ + { + "id": "T1136.001", + "name": "Local Account", + "reference": "https://attack.mitre.org/techniques/T1136/001/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0004", + "name": "Privilege Escalation", + "reference": "https://attack.mitre.org/tactics/TA0004/" + }, + "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/" + } + ] + }, + { + "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": 2 + }, + "id": "192657ba-ab0e-4901-89a2-911d611eee98_2", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/19de8096-e2b0-4bd8-80c9-34a820813fff_209.json b/packages/security_detection_engine/kibana/security_rule/19de8096-e2b0-4bd8-80c9-34a820813fff_209.json new file mode 100644 index 00000000000..53e386f6a1b --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/19de8096-e2b0-4bd8-80c9-34a820813fff_209.json @@ -0,0 +1,43 @@ +{ + "attributes": { + "anomaly_threshold": 50, + "author": [ + "Elastic" + ], + "description": "A machine learning job detected an unusual error in a CloudTrail message. These can be byproducts of attempted or successful persistence, privilege escalation, defense evasion, discovery, lateral movement, or collection.", + "false_positives": [ + "Rare and unusual errors may indicate an impending service failure state. Rare and unusual user error activity can also be due to manual troubleshooting or reconfiguration attempts by insufficiently privileged users, bugs in cloud automation scripts or workflows, or changes to IAM privileges." + ], + "from": "now-2h", + "interval": "15m", + "license": "Elastic License v2", + "machine_learning_job_id": "rare_error_code", + "name": "Rare AWS Error Code", + "note": "## Triage and analysis\n\n### Investigating Rare AWS Error Code\n\nCloudTrail logging provides visibility on actions taken within an AWS environment. By monitoring these events and understanding what is considered normal behavior within an organization, you can spot suspicious or malicious activity when deviations occur.\n\nThis rule uses a machine learning job to detect an unusual error in a CloudTrail message. This can be byproducts of attempted or successful persistence, privilege escalation, defense evasion, discovery, lateral movement, or collection.\n\nDetection alerts from this rule indicate a rare and unusual error code that was associated with the response to an AWS API command or method call.\n\n#### Possible investigation steps\n\n- Examine the history of the error. If the error only manifested recently, it might be related to recent changes in an automation module or script. You can find the error in the `aws.cloudtrail.error_code field` field.\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- Examine the history of the command. If the command only manifested recently, it might be part of a new automation module or script. If it has a consistent cadence (for example, it appears in small numbers on a weekly or monthly cadence), it might be part of a housekeeping or maintenance process. You can find the command in the `event.action field` field.\n- The adoption of new services or the addition of new functionality to scripts may generate false positives.\n\n### Related Rules\n\n- Unusual City For an AWS Command - 809b70d3-e2c3-455e-af1b-2626a5a1a276\n- Unusual Country For an AWS Command - dca28dee-c999-400f-b640-50a081cc0fd1\n- Unusual AWS Command for a User - ac706eae-d5ec-4b14-b4fd-e8ba8086f0e1\n- Spike in AWS Error Messages - 78d3d8d9-b476-451d-a9e0-7a5addd70670\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", + "references": [ + "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html" + ], + "related_integrations": [ + { + "package": "aws", + "version": "^2.0.0" + } + ], + "risk_score": 21, + "rule_id": "19de8096-e2b0-4bd8-80c9-34a820813fff", + "setup": "## Setup\n\nThis rule requires the installation of associated Machine Learning jobs, as well as data coming in from AWS.\n\n### Anomaly Detection Setup\n\nOnce the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the \"Definition\" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).\n\n### AWS Integration Setup\nThe AWS integration allows you to collect logs and metrics from Amazon Web Services (AWS) with Elastic Agent.\n\n#### The following steps should be executed in order to add the Elastic Agent System integration \"aws\" to your system:\n- Go to the Kibana home page and click \u201cAdd integrations\u201d.\n- In the query bar, search for \u201cAWS\u201d and select the integration to see more details about it.\n- Click \u201cAdd AWS\u201d.\n- Configure the integration name and optionally add a description.\n- Review optional and advanced settings accordingly.\n- Add the newly installed \u201caws\u201d to an existing or a new agent policy, and deploy the agent on your system from which aws log files are desirable.\n- Click \u201cSave and Continue\u201d.\n- For more details on the integration refer to the [helper guide](https://www.elastic.co/docs/current/integrations/aws).\n", + "severity": "low", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Rule Type: ML", + "Rule Type: Machine Learning", + "Resources: Investigation Guide" + ], + "type": "machine_learning", + "version": 209 + }, + "id": "19de8096-e2b0-4bd8-80c9-34a820813fff_209", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/1e9fc667-9ff1-4b33-9f40-fefca8537eb0_104.json b/packages/security_detection_engine/kibana/security_rule/1e9fc667-9ff1-4b33-9f40-fefca8537eb0_104.json new file mode 100644 index 00000000000..fc388ca8351 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/1e9fc667-9ff1-4b33-9f40-fefca8537eb0_104.json @@ -0,0 +1,77 @@ +{ + "attributes": { + "anomaly_threshold": 75, + "author": [ + "Elastic" + ], + "description": "Looks for sudo activity from an unusual user context. An unusual sudo user could be due to troubleshooting activity or it could be a sign of credentialed access via compromised accounts.", + "false_positives": [ + "Uncommon sudo activity can be due to an engineer logging onto a server instance in order to perform manual troubleshooting or reconfiguration." + ], + "from": "now-45m", + "interval": "15m", + "license": "Elastic License v2", + "machine_learning_job_id": [ + "v3_linux_rare_sudo_user" + ], + "name": "Unusual Sudo Activity", + "related_integrations": [ + { + "package": "auditd_manager", + "version": "^1.0.0" + }, + { + "package": "endpoint", + "version": "^8.2.0" + } + ], + "risk_score": 21, + "rule_id": "1e9fc667-9ff1-4b33-9f40-fefca8537eb0", + "setup": "## Setup\n\nThis rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:\n- Elastic Defend\n- Auditd Manager\n\n### Anomaly Detection Setup\n\nOnce the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the \"Definition\" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).\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 to your 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/current/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\n### Auditd Manager Integration Setup\nThe Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel.\nAuditd Manager 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.\n\n#### The following steps should be executed in order to add the Elastic Agent System integration \"auditd_manager\" to your system:\n- Go to the Kibana home page and click \u201cAdd integrations\u201d.\n- In the query bar, search for \u201cAuditd Manager\u201d and select the integration to see more details about it.\n- Click \u201cAdd Auditd Manager\u201d.\n- Configure the integration name and optionally add a description.\n- Review optional and advanced settings accordingly.\n- Add the newly installed \u201cauditd manager\u201d to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable.\n- Click \u201cSave and Continue\u201d.\n- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/auditd_manager).\n\n#### Rule Specific Setup Note\nAuditd Manager subscribes to the kernel and receives events as they occur without any additional configuration.\nHowever, 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.\n- For this detection rule no additional audit rules are required.\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Rule Type: ML", + "Rule Type: Machine Learning", + "Tactic: Privilege Escalation" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1548", + "name": "Abuse Elevation Control Mechanism", + "reference": "https://attack.mitre.org/techniques/T1548/" + } + ] + }, + { + "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/" + } + ] + } + ], + "type": "machine_learning", + "version": 104 + }, + "id": "1e9fc667-9ff1-4b33-9f40-fefca8537eb0_104", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/1faec04b-d902-4f89-8aff-92cd9043c16f_104.json b/packages/security_detection_engine/kibana/security_rule/1faec04b-d902-4f89-8aff-92cd9043c16f_104.json new file mode 100644 index 00000000000..ac8c438999e --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/1faec04b-d902-4f89-8aff-92cd9043c16f_104.json @@ -0,0 +1,69 @@ +{ + "attributes": { + "anomaly_threshold": 75, + "author": [ + "Elastic" + ], + "description": "Looks for anomalous access to the cloud platform metadata service by an unusual user. The metadata service may be targeted in order to harvest credentials or user data scripts containing secrets.", + "false_positives": [ + "A newly installed program, or one that runs under a new or rarely used user context, could trigger this detection rule. Manual interrogation of the metadata service during debugging or troubleshooting could trigger this rule." + ], + "from": "now-45m", + "interval": "15m", + "license": "Elastic License v2", + "machine_learning_job_id": [ + "v3_linux_rare_metadata_user" + ], + "name": "Unusual Linux User Calling the Metadata Service", + "related_integrations": [ + { + "package": "auditd_manager", + "version": "^1.0.0" + }, + { + "package": "endpoint", + "version": "^8.2.0" + } + ], + "risk_score": 21, + "rule_id": "1faec04b-d902-4f89-8aff-92cd9043c16f", + "setup": "## Setup\n\nThis rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:\n- Elastic Defend\n- Auditd Manager\n\n### Anomaly Detection Setup\n\nOnce the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the \"Definition\" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).\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 to your 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/current/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\n### Auditd Manager Integration Setup\nThe Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel.\nAuditd Manager 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.\n\n#### The following steps should be executed in order to add the Elastic Agent System integration \"auditd_manager\" to your system:\n- Go to the Kibana home page and click \u201cAdd integrations\u201d.\n- In the query bar, search for \u201cAuditd Manager\u201d and select the integration to see more details about it.\n- Click \u201cAdd Auditd Manager\u201d.\n- Configure the integration name and optionally add a description.\n- Review optional and advanced settings accordingly.\n- Add the newly installed \u201cauditd manager\u201d to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable.\n- Click \u201cSave and Continue\u201d.\n- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/auditd_manager).\n\n#### Rule Specific Setup Note\nAuditd Manager subscribes to the kernel and receives events as they occur without any additional configuration.\nHowever, 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.\n- For this detection rule no additional audit rules are required.\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Rule Type: ML", + "Rule Type: Machine Learning", + "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/" + } + ] + } + ] + } + ], + "type": "machine_learning", + "version": 104 + }, + "id": "1faec04b-d902-4f89-8aff-92cd9043c16f_104", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/23f18264-2d6d-11ef-9413-f661ea17fbce_1.json b/packages/security_detection_engine/kibana/security_rule/23f18264-2d6d-11ef-9413-f661ea17fbce_1.json new file mode 100644 index 00000000000..d958fbc5fa5 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/23f18264-2d6d-11ef-9413-f661ea17fbce_1.json @@ -0,0 +1,75 @@ +{ + "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| 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/" + ], + "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": 1 + }, + "id": "23f18264-2d6d-11ef-9413-f661ea17fbce_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_101.json b/packages/security_detection_engine/kibana/security_rule/2e56e1bc-867a-11ee-b13e-f661ea17fbcd_101.json new file mode 100644 index 00000000000..d2c28ecbbdb --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/2e56e1bc-867a-11ee-b13e-f661ea17fbcd_101.json @@ -0,0 +1,60 @@ +{ + "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| 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/" + ], + "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": 101 + }, + "id": "2e56e1bc-867a-11ee-b13e-f661ea17fbcd_101", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/35f86980-1fb1-4dff-b311-3be941549c8d_104.json b/packages/security_detection_engine/kibana/security_rule/35f86980-1fb1-4dff-b311-3be941549c8d_104.json new file mode 100644 index 00000000000..72e7b13afe3 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/35f86980-1fb1-4dff-b311-3be941549c8d_104.json @@ -0,0 +1,43 @@ +{ + "attributes": { + "anomaly_threshold": 75, + "author": [ + "Elastic" + ], + "description": "A machine learning job detected a rare destination country name in the network logs. This can be due to initial access, persistence, command-and-control, or exfiltration activity. For example, when a user clicks on a link in a phishing email or opens a malicious document, a request may be sent to download and run a payload from a server in a country which does not normally appear in network traffic or business work-flows. Malware instances and persistence mechanisms may communicate with command-and-control (C2) infrastructure in their country of origin, which may be an unusual destination country for the source network.", + "false_positives": [ + "Business workflows that occur very occasionally, and involve a business relationship with an organization in a country that does not routinely appear in network events, can trigger this alert. A new business workflow with an organization in a country with which no workflows previously existed may trigger this alert - although the model will learn that the new destination country is no longer anomalous as the activity becomes ongoing. Business travelers who roam to many countries for brief periods may trigger this alert." + ], + "from": "now-30m", + "interval": "15m", + "license": "Elastic License v2", + "machine_learning_job_id": "rare_destination_country", + "name": "Network Traffic to Rare Destination Country", + "references": [ + "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "network_traffic", + "version": "^1.1.0" + } + ], + "risk_score": 21, + "rule_id": "35f86980-1fb1-4dff-b311-3be941549c8d", + "setup": "## Setup\n\nThis rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:\n- Elastic Defend\n- Network Packet Capture\n\n### Anomaly Detection Setup\n\nOnce the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the \"Definition\" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).\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 to your 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/current/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\n### Network Packet Capture Integration Setup\nThe Network Packet Capture integration sniffs network packets on a host and dissects known protocols. Monitoring the network traffic is critical to gaining observability and securing your environment \u2014 ensuring high levels of performance and security. The Network Packet Capture integration captures the network traffic between your application servers, decodes common application layer protocols and records the interesting fields for each transaction.\n\n#### The following steps should be executed in order to add the Elastic Agent System integration \"network_traffic\" to your system:\n- Go to the Kibana home page and click \u201cAdd integrations\u201d.\n- In the query bar, search for \u201cNetwork Packet Capture\u201d and select the integration to see more details about it.\n- Click \u201cAdd Network Packet Capture\u201d.\n- Configure the integration name and optionally add a description.\n- Review optional and advanced settings accordingly.\n- Add the newly installed \u201cnetwork_traffic\u201d to an existing or a new agent policy, and deploy the agent on your system from which network log files are desirable.\n- Click \u201cSave and Continue\u201d.\n- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/network_traffic).\n", + "severity": "low", + "tags": [ + "Use Case: Threat Detection", + "Rule Type: ML", + "Rule Type: Machine Learning" + ], + "type": "machine_learning", + "version": 104 + }, + "id": "35f86980-1fb1-4dff-b311-3be941549c8d_104", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/3a657da0-1df2-11ef-a327-f661ea17fbcc_1.json b/packages/security_detection_engine/kibana/security_rule/3a657da0-1df2-11ef-a327-f661ea17fbcc_1.json new file mode 100644 index 00000000000..235840b0a19 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/3a657da0-1df2-11ef-a327-f661ea17fbcc_1.json @@ -0,0 +1,97 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule is triggered when CVEs collected from the Rapid7 Threat Command Integration have a match against vulnerabilities that were found in the customer environment.", + "filters": [ + { + "$state": { + "store": "appState" + }, + "meta": { + "disabled": false, + "key": "rapid7.tc.vulnerability.id", + "negate": true, + "type": "exists" + }, + "query": { + "exists": { + "field": "rapid7.tc.vulnerability.id" + } + } + } + ], + "from": "now-35m", + "index": [ + "auditbeat-*", + "endgame-*", + "filebeat-*", + "logs-*", + "packetbeat-*", + "winlogbeat-*" + ], + "interval": "30m", + "language": "kuery", + "license": "Elastic License v2", + "max_signals": 10000, + "name": "Rapid7 Threat Command CVEs Correlation", + "note": "## Triage and Analysis\n\n### Investigating Rapid7 Threat Command CVEs Correlation\n\nRapid7 Threat Command CVEs Correlation rule allows matching CVEs from user indices within the vulnerabilities collected from Rapid7 Threat Command integrations.\n\nThe matches will be based on the latest values of CVEs from the last 180 days. So it's essential to validate the data and review the results by investigating the associated activity to determine if it requires further investigation.\n\nIf a vulnerability matches a local observation, the following enriched fields will be generated to identify the vulnerability, field, and type matched.\n\n- `threat.indicator.matched.atomic` - this identifies the atomic vulnerability that matched the local observation\n- `threat.indicator.matched.field` - this identifies the vulnerability field that matched the local observation\n- `threat.indicator.matched.type` - this identifies the vulnerability type that matched the local observation\n\nAdditional investigation can be done by reviewing the source of the activity and considering the history of the vulnerability that was matched. This can help understand if the activity is related to legitimate behavior.\n\n- Investigation can be validated and reviewed based on the data that was matched and by viewing the source of that activity.\n- Consider the history of the vulnerability that was matched. Has it happened before? Is it happening on multiple machines? These kinds of questions can help understand if the activity is related to legitimate behavior.\n- Consider the user and their role within the company: is this something related to their job or work function?\n", + "query": "vulnerability.id : *\n", + "references": [ + "https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-threatintel.html", + "https://docs.elastic.co/integrations/ti_rapid7_threat_command" + ], + "related_integrations": [ + { + "package": "ti_rapid7_threat_command", + "version": "^1.0.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "vulnerability.id", + "type": "keyword" + } + ], + "risk_score": 99, + "rule_id": "3a657da0-1df2-11ef-a327-f661ea17fbcc", + "setup": "\n## Setup\n\nThis rule needs threat intelligence indicators to work.\nThreat intelligence indicators can be collected using an [Elastic Agent integration](https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html#agent-ti-integration),\nthe [Threat Intel module](https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html#ti-mod-integration),\nor a [custom integration](https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html#custom-ti-integration).\n\nMore information can be found [here](https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html).\n\n## Max Signals\n\nThis rule is configured to generate more **Max alerts per run** than the default 1000 alerts per run set for all rules. This is to ensure that it captures as many alerts as possible.\n\n**IMPORTANT:** The rule's **Max alerts per run** setting can be superseded by the `xpack.alerting.rules.run.alerts.max` Kibana config setting, which determines the maximum alerts generated by _any_ rule in the Kibana alerting framework. For example, if `xpack.alerting.rules.run.alerts.max` is set to 1000, this rule will still generate no more than 1000 alerts even if its own **Max alerts per run** is set higher.\n\nTo make sure this rule can generate as many alerts as it's configured in its own **Max alerts per run** setting, increase the `xpack.alerting.rules.run.alerts.max` system setting accordingly.\n\n**NOTE:** Changing `xpack.alerting.rules.run.alerts.max` is not possible in Serverless projects.\n", + "severity": "critical", + "tags": [ + "OS: Windows", + "Data Source: Elastic Endgame", + "Data Source: Windows", + "Data Source: Network", + "Data Source: Rapid7 Threat Command", + "Rule Type: Threat Match", + "Resources: Investigation Guide", + "Use Case: Vulnerability", + "Use Case: Asset Visibility", + "Use Case: Continuous Monitoring" + ], + "threat_index": [ + "logs-ti_rapid7_threat_command_latest.vulnerability" + ], + "threat_indicator_path": "rapid7.tc.vulnerability", + "threat_language": "kuery", + "threat_mapping": [ + { + "entries": [ + { + "field": "vulnerability.id", + "type": "mapping", + "value": "vulnerability.id" + } + ] + } + ], + "threat_query": "@timestamp >= \"now-30d/d\" and vulnerability.id : * and event.module: ti_rapid7_threat_command", + "timestamp_override": "event.ingested", + "type": "threat_match", + "version": 1 + }, + "id": "3a657da0-1df2-11ef-a327-f661ea17fbcc_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/3c7e32e6-6104-46d9-a06e-da0f8b5795a0_104.json b/packages/security_detection_engine/kibana/security_rule/3c7e32e6-6104-46d9-a06e-da0f8b5795a0_104.json new file mode 100644 index 00000000000..829408dfd88 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/3c7e32e6-6104-46d9-a06e-da0f8b5795a0_104.json @@ -0,0 +1,47 @@ +{ + "attributes": { + "anomaly_threshold": 50, + "author": [ + "Elastic" + ], + "description": "Identifies unusual destination port activity that can indicate command-and-control, persistence mechanism, or data exfiltration activity. Rarely used destination port activity is generally unusual in Linux fleets, and can indicate unauthorized access or threat actor activity.", + "false_positives": [ + "A newly installed program or one that rarely uses the network could trigger this alert." + ], + "from": "now-45m", + "interval": "15m", + "license": "Elastic License v2", + "machine_learning_job_id": [ + "v3_linux_anomalous_network_port_activity" + ], + "name": "Unusual Linux Network Port Activity", + "references": [ + "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html" + ], + "related_integrations": [ + { + "package": "auditd_manager", + "version": "^1.0.0" + }, + { + "package": "endpoint", + "version": "^8.2.0" + } + ], + "risk_score": 21, + "rule_id": "3c7e32e6-6104-46d9-a06e-da0f8b5795a0", + "setup": "## Setup\n\nThis rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:\n- Elastic Defend\n- Auditd Manager\n\n### Anomaly Detection Setup\n\nOnce the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the \"Definition\" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).\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 to your 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/current/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\n### Auditd Manager Integration Setup\nThe Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel.\nAuditd Manager 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.\n\n#### The following steps should be executed in order to add the Elastic Agent System integration \"auditd_manager\" to your system:\n- Go to the Kibana home page and click \u201cAdd integrations\u201d.\n- In the query bar, search for \u201cAuditd Manager\u201d and select the integration to see more details about it.\n- Click \u201cAdd Auditd Manager\u201d.\n- Configure the integration name and optionally add a description.\n- Review optional and advanced settings accordingly.\n- Add the newly installed \u201cauditd manager\u201d to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable.\n- Click \u201cSave and Continue\u201d.\n- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/auditd_manager).\n\n#### Rule Specific Setup Note\nAuditd Manager subscribes to the kernel and receives events as they occur without any additional configuration.\nHowever, 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.\n- For this detection rule no additional audit rules are required.\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Rule Type: ML", + "Rule Type: Machine Learning" + ], + "type": "machine_learning", + "version": 104 + }, + "id": "3c7e32e6-6104-46d9-a06e-da0f8b5795a0_104", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/4330272b-9724-4bc6-a3ca-f1532b81e5c2_104.json b/packages/security_detection_engine/kibana/security_rule/4330272b-9724-4bc6-a3ca-f1532b81e5c2_104.json new file mode 100644 index 00000000000..3bc5a56c166 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/4330272b-9724-4bc6-a3ca-f1532b81e5c2_104.json @@ -0,0 +1,66 @@ +{ + "attributes": { + "anomaly_threshold": 50, + "author": [ + "Elastic" + ], + "description": "Identifies an unusually high number of authentication attempts.", + "false_positives": [ + "Security audits may trigger this alert. Conditions that generate bursts of failed logins, such as misconfigured applications or account lockouts could trigger this alert." + ], + "from": "now-45m", + "interval": "15m", + "license": "Elastic License v2", + "machine_learning_job_id": "suspicious_login_activity", + "name": "Unusual Login Activity", + "references": [ + "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html" + ], + "related_integrations": [ + { + "package": "auditd_manager", + "version": "^1.0.0" + }, + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "system", + "version": "^1.6.4" + } + ], + "risk_score": 21, + "rule_id": "4330272b-9724-4bc6-a3ca-f1532b81e5c2", + "setup": "## Setup\n\nThis rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:\n- Elastic Defend\n- Auditd Manager\n- System\n\n### Anomaly Detection Setup\n\nOnce the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the \"Definition\" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).\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 to your 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/current/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\n### Auditd Manager Integration Setup\nThe Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel.\nAuditd Manager 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.\n\n#### The following steps should be executed in order to add the Elastic Agent System integration \"auditd_manager\" to your system:\n- Go to the Kibana home page and click \u201cAdd integrations\u201d.\n- In the query bar, search for \u201cAuditd Manager\u201d and select the integration to see more details about it.\n- Click \u201cAdd Auditd Manager\u201d.\n- Configure the integration name and optionally add a description.\n- Review optional and advanced settings accordingly.\n- Add the newly installed \u201cauditd manager\u201d to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable.\n- Click \u201cSave and Continue\u201d.\n- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/auditd_manager).\n\n#### Rule Specific Setup Note\nAuditd Manager subscribes to the kernel and receives events as they occur without any additional configuration.\nHowever, 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.\n- For this detection rule no additional audit rules are required.\n\n### System Integration Setup\nThe System integration allows you to collect system logs and metrics from your servers with Elastic Agent.\n\n#### The following steps should be executed in order to add the Elastic Agent System integration \"system\" to your system:\n- Go to the Kibana home page and click \u201cAdd integrations\u201d.\n- In the query bar, search for \u201cSystem\u201d and select the integration to see more details about it.\n- Click \u201cAdd System\u201d.\n- Configure the integration name and optionally add a description.\n- Review optional and advanced settings accordingly.\n- Add the newly installed \u201csystem\u201d to an existing or a new agent policy, and deploy the agent on your system from which system log files are desirable.\n- Click \u201cSave and Continue\u201d.\n- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/system).\n", + "severity": "low", + "tags": [ + "Use Case: Identity and Access Audit", + "Use Case: Threat Detection", + "Rule Type: ML", + "Rule Type: Machine Learning", + "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/" + } + ] + } + ], + "type": "machine_learning", + "version": 104 + }, + "id": "4330272b-9724-4bc6-a3ca-f1532b81e5c2_104", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/445a342e-03fb-42d0-8656-0367eb2dead5_105.json b/packages/security_detection_engine/kibana/security_rule/445a342e-03fb-42d0-8656-0367eb2dead5_105.json new file mode 100644 index 00000000000..177bd528359 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/445a342e-03fb-42d0-8656-0367eb2dead5_105.json @@ -0,0 +1,95 @@ +{ + "attributes": { + "anomaly_threshold": 50, + "author": [ + "Elastic" + ], + "description": "Identifies processes started from atypical folders in the file system, which might indicate malware execution or persistence mechanisms. In corporate Windows environments, software installation is centrally managed and it is unusual for programs to be executed from user or temporary directories. Processes executed from these locations can denote that a user downloaded software directly from the Internet or a malicious script or macro executed malware.", + "false_positives": [ + "A new and unusual program or artifact download in the course of software upgrades, debugging, or troubleshooting could trigger this alert. Users downloading and running programs from unusual locations, such as temporary directories, browser caches, or profile paths could trigger this alert." + ], + "from": "now-45m", + "interval": "15m", + "license": "Elastic License v2", + "machine_learning_job_id": [ + "v3_windows_anomalous_path_activity" + ], + "name": "Unusual Windows Path Activity", + "references": [ + "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "windows", + "version": "^1.5.0" + } + ], + "risk_score": 21, + "rule_id": "445a342e-03fb-42d0-8656-0367eb2dead5", + "setup": "## Setup\n\nThis rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:\n- Elastic Defend\n- Windows\n\n### Anomaly Detection Setup\n\nOnce the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the \"Definition\" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).\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 to your 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/current/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\n### Windows Integration Setup\nThe Windows integration allows you to monitor the Windows OS, services, applications, and more.\n\n#### The following steps should be executed in order to add the Elastic Agent System integration \"windows\" to your system:\n- Go to the Kibana home page and click \u201cAdd integrations\u201d.\n- In the query bar, search for \u201cWindows\u201d and select the integration to see more details about it.\n- Click \u201cAdd Windows\u201d.\n- Configure the integration name and optionally add a description.\n- Review optional and advanced settings accordingly.\n- Add the newly installed \u201cwindows\u201d to an existing or a new agent policy, and deploy the agent on your system from which windows log files are desirable.\n- Click \u201cSave and Continue\u201d.\n- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/windows).\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Rule Type: ML", + "Rule Type: Machine Learning", + "Tactic: Persistence", + "Tactic: Execution" + ], + "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": "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/" + } + ] + } + ] + } + ], + "type": "machine_learning", + "version": 105 + }, + "id": "445a342e-03fb-42d0-8656-0367eb2dead5_105", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/46f804f5-b289-43d6-a881-9387cf594f75_105.json b/packages/security_detection_engine/kibana/security_rule/46f804f5-b289-43d6-a881-9387cf594f75_105.json new file mode 100644 index 00000000000..1787b1ada6e --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/46f804f5-b289-43d6-a881-9387cf594f75_105.json @@ -0,0 +1,73 @@ +{ + "attributes": { + "anomaly_threshold": 50, + "author": [ + "Elastic" + ], + "description": "Identifies rare processes that do not usually run on individual hosts, which can indicate execution of unauthorized services, malware, or persistence mechanisms. Processes are considered rare when they only run occasionally as compared with other processes running on the host.", + "false_positives": [ + "A newly installed program or one that runs rarely as part of a monthly or quarterly workflow could trigger this alert." + ], + "from": "now-45m", + "interval": "15m", + "license": "Elastic License v2", + "machine_learning_job_id": [ + "v3_rare_process_by_host_linux" + ], + "name": "Unusual Process For a Linux Host", + "note": "## Triage and analysis\n\n### Investigating Unusual Process For a Linux Host\n\nSearching for abnormal Linux processes is a good methodology to find potentially malicious activity within a network. Understanding what is commonly run within an environment and developing baselines for legitimate activity can help uncover potential malware and suspicious behaviors.\n\nThis rule uses a machine learning job to detect a Linux process that is rare and unusual for an individual Linux host in your environment.\n\n#### Possible investigation steps\n\n- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, and whether they are located in expected locations.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Consider the user as identified by the `user.name` field. Is this program part of an expected workflow for the user who ran this program on this host?\n- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations.\n- Validate if the activity has a consistent cadence (for example, if it runs monthly or quarterly), as it could be part of a monthly or quarterly business process.\n- Examine the arguments and working directory of the process. These may provide indications as to the source of the program or the nature of the tasks it is performing.\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- 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 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- 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", + "references": [ + "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html" + ], + "related_integrations": [ + { + "package": "auditd_manager", + "version": "^1.0.0" + }, + { + "package": "endpoint", + "version": "^8.2.0" + } + ], + "risk_score": 21, + "rule_id": "46f804f5-b289-43d6-a881-9387cf594f75", + "setup": "## Setup\n\nThis rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:\n- Elastic Defend\n- Auditd Manager\n\n### Anomaly Detection Setup\n\nOnce the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the \"Definition\" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).\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 to your 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/current/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\n### Auditd Manager Integration Setup\nThe Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel.\nAuditd Manager 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.\n\n#### The following steps should be executed in order to add the Elastic Agent System integration \"auditd_manager\" to your system:\n- Go to the Kibana home page and click \u201cAdd integrations\u201d.\n- In the query bar, search for \u201cAuditd Manager\u201d and select the integration to see more details about it.\n- Click \u201cAdd Auditd Manager\u201d.\n- Configure the integration name and optionally add a description.\n- Review optional and advanced settings accordingly.\n- Add the newly installed \u201cauditd manager\u201d to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable.\n- Click \u201cSave and Continue\u201d.\n- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/auditd_manager).\n\n#### Rule Specific Setup Note\nAuditd Manager subscribes to the kernel and receives events as they occur without any additional configuration.\nHowever, 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.\n- For this detection rule no additional audit rules are required.\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Rule Type: ML", + "Rule Type: Machine Learning", + "Tactic: Persistence" + ], + "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.002", + "name": "Systemd Service", + "reference": "https://attack.mitre.org/techniques/T1543/002/" + } + ] + } + ] + } + ], + "type": "machine_learning", + "version": 105 + }, + "id": "46f804f5-b289-43d6-a881-9387cf594f75_105", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/493834ca-f861-414c-8602-150d5505b777_102.json b/packages/security_detection_engine/kibana/security_rule/493834ca-f861-414c-8602-150d5505b777_102.json new file mode 100644 index 00000000000..d9f52184420 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/493834ca-f861-414c-8602-150d5505b777_102.json @@ -0,0 +1,74 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Detects when multiple hosts are using the same agent ID. This could occur in the event of an agent being taken over and used to inject illegitimate documents into an instance as an attempt to spoof events in order to masquerade actual activity to evade detection.", + "false_positives": [ + "This is meant to run only on datasources using Elastic Agent 7.14+ since versions prior to that will be missing the necessary field, resulting in false positives." + ], + "from": "now-9m", + "index": [ + "logs-*", + "metrics-*", + "traces-*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "Agent Spoofing - Multiple Hosts Using Same Agent", + "query": "event.agent_id_status:* and not tags:forwarded\n", + "required_fields": [ + { + "ecs": true, + "name": "event.agent_id_status", + "type": "keyword" + }, + { + "ecs": true, + "name": "tags", + "type": "keyword" + } + ], + "risk_score": 73, + "rule_id": "493834ca-f861-414c-8602-150d5505b777", + "severity": "high", + "tags": [ + "Use Case: Threat Detection", + "Tactic: Defense Evasion" + ], + "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/" + } + ] + } + ], + "threshold": { + "cardinality": [ + { + "field": "host.id", + "value": 2 + } + ], + "field": [ + "agent.id" + ], + "value": 2 + }, + "timestamp_override": "event.ingested", + "type": "threshold", + "version": 102 + }, + "id": "493834ca-f861-414c-8602-150d5505b777_102", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/52afbdc5-db15-485e-bc24-f5707f820c4b_104.json b/packages/security_detection_engine/kibana/security_rule/52afbdc5-db15-485e-bc24-f5707f820c4b_104.json new file mode 100644 index 00000000000..e3ca4cad058 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/52afbdc5-db15-485e-bc24-f5707f820c4b_104.json @@ -0,0 +1,45 @@ +{ + "attributes": { + "anomaly_threshold": 50, + "author": [ + "Elastic" + ], + "description": "Identifies Linux processes that do not usually use the network but have unexpected network activity, which can indicate command-and-control, lateral movement, persistence, or data exfiltration activity. A process with unusual network activity can denote process exploitation or injection, where the process is used to run persistence mechanisms that allow a malicious actor remote access or control of the host, data exfiltration, and execution of unauthorized network applications.", + "from": "now-45m", + "interval": "15m", + "license": "Elastic License v2", + "machine_learning_job_id": [ + "v3_linux_anomalous_network_activity" + ], + "name": "Unusual Linux Network Activity", + "note": "## Triage and analysis\n\n### Investigating Unusual Network Activity\nDetection alerts from this rule indicate the presence of network activity from a Linux process for which network activity is rare and unusual. Here are some possible avenues of investigation:\n- Consider the IP addresses and ports. Are these used by normal but infrequent network workflows? Are they expected or unexpected?\n- If the destination IP address is remote or external, does it associate with an expected domain, organization or geography? Note: avoid interacting directly with suspected malicious IP addresses.\n- Consider the user as identified by the username field. Is this network activity part of an expected workflow for the user who ran the program?\n- Examine the history of execution. If this process only manifested recently, it might be part of a new software package. If it has a consistent cadence (for example if it runs monthly or quarterly), it might be part of a monthly or quarterly business or maintenance process.\n- Examine the process arguments, title and working directory. These may provide indications as to the source of the program or the nature of the tasks it is performing.", + "references": [ + "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html" + ], + "related_integrations": [ + { + "package": "auditd_manager", + "version": "^1.0.0" + }, + { + "package": "endpoint", + "version": "^8.2.0" + } + ], + "risk_score": 21, + "rule_id": "52afbdc5-db15-485e-bc24-f5707f820c4b", + "setup": "## Setup\n\nThis rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:\n- Elastic Defend\n- Auditd Manager\n\n### Anomaly Detection Setup\n\nOnce the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the \"Definition\" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).\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 to your 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/current/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\n### Auditd Manager Integration Setup\nThe Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel.\nAuditd Manager 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.\n\n#### The following steps should be executed in order to add the Elastic Agent System integration \"auditd_manager\" to your system:\n- Go to the Kibana home page and click \u201cAdd integrations\u201d.\n- In the query bar, search for \u201cAuditd Manager\u201d and select the integration to see more details about it.\n- Click \u201cAdd Auditd Manager\u201d.\n- Configure the integration name and optionally add a description.\n- Review optional and advanced settings accordingly.\n- Add the newly installed \u201cauditd manager\u201d to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable.\n- Click \u201cSave and Continue\u201d.\n- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/auditd_manager).\n\n#### Rule Specific Setup Note\nAuditd Manager subscribes to the kernel and receives events as they occur without any additional configuration.\nHowever, 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.\n- For this detection rule no additional audit rules are required.\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Rule Type: ML", + "Rule Type: Machine Learning" + ], + "type": "machine_learning", + "version": 104 + }, + "id": "52afbdc5-db15-485e-bc24-f5707f820c4b_104", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/57bfa0a9-37c0-44d6-b724-54bf16787492_1.json b/packages/security_detection_engine/kibana/security_rule/57bfa0a9-37c0-44d6-b724-54bf16787492_1.json new file mode 100644 index 00000000000..b181a682bcd --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/57bfa0a9-37c0-44d6-b724-54bf16787492_1.json @@ -0,0 +1,109 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies changes to the DNS Global Query Block List (GQBL), a security feature that prevents the resolution of certain DNS names often exploited in attacks like WPAD spoofing. Attackers with certain privileges, such as DNSAdmins, can modify or disable the GQBL, allowing exploitation of hosts running WPAD with default settings for privilege escalation and lateral movement.", + "from": "now-9m", + "index": [ + "logs-endpoint.events.registry-*", + "logs-windows.sysmon_operational-*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "DNS Global Query Block List Modified or Disabled", + "query": "registry where host.os.type == \"windows\" and event.type : \"change\" and\n(\n (registry.value : \"EnableGlobalQueryBlockList\" and registry.data.strings : (\"0\", \"0x00000000\")) or\n (registry.value : \"GlobalQueryBlockList\" and not registry.data.strings : \"wpad\")\n)\n", + "references": [ + "https://cube0x0.github.io/Pocing-Beyond-DA/", + "https://www.thehacker.recipes/ad/movement/mitm-and-coerced-authentications/wpad-spoofing", + "https://www.netspi.com/blog/technical-blog/network-penetration-testing/adidns-revisited/" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "windows", + "version": "^1.5.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.value", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "57bfa0a9-37c0-44d6-b724-54bf16787492", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "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": "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/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0006", + "name": "Credential Access", + "reference": "https://attack.mitre.org/tactics/TA0006/" + }, + "technique": [ + { + "id": "T1557", + "name": "Adversary-in-the-Middle", + "reference": "https://attack.mitre.org/techniques/T1557/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 1 + }, + "id": "57bfa0a9-37c0-44d6-b724-54bf16787492_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/59756272-1998-4b8c-be14-e287035c4d10_105.json b/packages/security_detection_engine/kibana/security_rule/59756272-1998-4b8c-be14-e287035c4d10_105.json new file mode 100644 index 00000000000..1bf6592d64b --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/59756272-1998-4b8c-be14-e287035c4d10_105.json @@ -0,0 +1,62 @@ +{ + "attributes": { + "anomaly_threshold": 75, + "author": [ + "Elastic" + ], + "description": "Looks for commands related to system user or owner discovery from an unusual user context. This can be due to uncommon troubleshooting activity or due to a compromised account. A compromised account may be used to engage in system owner or user discovery in order to identify currently active or primary users of a system. This may be a precursor to additional discovery, credential dumping or privilege elevation activity.", + "false_positives": [ + "Uncommon user command activity can be due to an engineer logging onto a server instance in order to perform manual troubleshooting or reconfiguration." + ], + "from": "now-45m", + "interval": "15m", + "license": "Elastic License v2", + "machine_learning_job_id": [ + "v3_linux_system_user_discovery" + ], + "name": "Unusual Linux User Discovery Activity", + "related_integrations": [ + { + "package": "auditd_manager", + "version": "^1.0.0" + }, + { + "package": "endpoint", + "version": "^8.2.0" + } + ], + "risk_score": 21, + "rule_id": "59756272-1998-4b8c-be14-e287035c4d10", + "setup": "## Setup\n\nThis rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:\n- Elastic Defend\n- Auditd Manager\n\n### Anomaly Detection Setup\n\nOnce the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the \"Definition\" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).\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 to your 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/current/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\n### Auditd Manager Integration Setup\nThe Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel.\nAuditd Manager 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.\n\n#### The following steps should be executed in order to add the Elastic Agent System integration \"auditd_manager\" to your system:\n- Go to the Kibana home page and click \u201cAdd integrations\u201d.\n- In the query bar, search for \u201cAuditd Manager\u201d and select the integration to see more details about it.\n- Click \u201cAdd Auditd Manager\u201d.\n- Configure the integration name and optionally add a description.\n- Review optional and advanced settings accordingly.\n- Add the newly installed \u201cauditd manager\u201d to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable.\n- Click \u201cSave and Continue\u201d.\n- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/auditd_manager).\n\n#### Rule Specific Setup Note\nAuditd Manager subscribes to the kernel and receives events as they occur without any additional configuration.\nHowever, 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.\n- For this detection rule no additional audit rules are required.\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Rule Type: ML", + "Rule Type: Machine Learning", + "Tactic: Discovery" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0007", + "name": "Discovery", + "reference": "https://attack.mitre.org/tactics/TA0007/" + }, + "technique": [ + { + "id": "T1033", + "name": "System Owner/User Discovery", + "reference": "https://attack.mitre.org/techniques/T1033/" + } + ] + } + ], + "type": "machine_learning", + "version": 105 + }, + "id": "59756272-1998-4b8c-be14-e287035c4d10_105", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/5c983105-4681-46c3-9890-0c66d05e776b_104.json b/packages/security_detection_engine/kibana/security_rule/5c983105-4681-46c3-9890-0c66d05e776b_104.json new file mode 100644 index 00000000000..39ebdb15b21 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/5c983105-4681-46c3-9890-0c66d05e776b_104.json @@ -0,0 +1,62 @@ +{ + "attributes": { + "anomaly_threshold": 50, + "author": [ + "Elastic" + ], + "description": "Looks for commands related to system process discovery from an unusual user context. This can be due to uncommon troubleshooting activity or due to a compromised account. A compromised account may be used by a threat actor to engage in system process discovery in order to increase their understanding of software applications running on a target host or network. This may be a precursor to selection of a persistence mechanism or a method of privilege elevation.", + "false_positives": [ + "Uncommon user command activity can be due to an engineer logging onto a server instance in order to perform manual troubleshooting or reconfiguration." + ], + "from": "now-45m", + "interval": "15m", + "license": "Elastic License v2", + "machine_learning_job_id": [ + "v3_linux_system_process_discovery" + ], + "name": "Unusual Linux Process Discovery Activity", + "related_integrations": [ + { + "package": "auditd_manager", + "version": "^1.0.0" + }, + { + "package": "endpoint", + "version": "^8.2.0" + } + ], + "risk_score": 21, + "rule_id": "5c983105-4681-46c3-9890-0c66d05e776b", + "setup": "## Setup\n\nThis rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:\n- Elastic Defend\n- Auditd Manager\n\n### Anomaly Detection Setup\n\nOnce the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the \"Definition\" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).\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 to your 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/current/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\n### Auditd Manager Integration Setup\nThe Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel.\nAuditd Manager 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.\n\n#### The following steps should be executed in order to add the Elastic Agent System integration \"auditd_manager\" to your system:\n- Go to the Kibana home page and click \u201cAdd integrations\u201d.\n- In the query bar, search for \u201cAuditd Manager\u201d and select the integration to see more details about it.\n- Click \u201cAdd Auditd Manager\u201d.\n- Configure the integration name and optionally add a description.\n- Review optional and advanced settings accordingly.\n- Add the newly installed \u201cauditd manager\u201d to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable.\n- Click \u201cSave and Continue\u201d.\n- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/auditd_manager).\n\n#### Rule Specific Setup Note\nAuditd Manager subscribes to the kernel and receives events as they occur without any additional configuration.\nHowever, 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.\n- For this detection rule no additional audit rules are required.\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Rule Type: ML", + "Rule Type: Machine Learning", + "Tactic: Discovery" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0007", + "name": "Discovery", + "reference": "https://attack.mitre.org/tactics/TA0007/" + }, + "technique": [ + { + "id": "T1057", + "name": "Process Discovery", + "reference": "https://attack.mitre.org/techniques/T1057/" + } + ] + } + ], + "type": "machine_learning", + "version": 104 + }, + "id": "5c983105-4681-46c3-9890-0c66d05e776b_104", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/5d676480-9655-4507-adc6-4eec311efff8_1.json b/packages/security_detection_engine/kibana/security_rule/5d676480-9655-4507-adc6-4eec311efff8_1.json new file mode 100644 index 00000000000..974654d5070 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/5d676480-9655-4507-adc6-4eec311efff8_1.json @@ -0,0 +1,98 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies unusual DLLs loaded by the DNS Server process, potentially indicating the abuse of the ServerLevelPluginDll functionality. This can lead to privilege escalation and remote code execution with SYSTEM privileges.", + "from": "now-9m", + "index": [ + "logs-endpoint.events.library-*", + "logs-windows.sysmon_operational-*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Unsigned DLL loaded by DNS Service", + "query": "any where host.os.type == \"windows\" and event.category : (\"library\", \"process\") and\n event.type : (\"start\", \"change\") and event.action : (\"load\", \"Image loaded*\") and\n process.executable : \"?:\\\\windows\\\\system32\\\\dns.exe\" and \n not ?dll.code_signature.trusted == true and\n not file.code_signature.status == \"Valid\"\n", + "references": [ + "https://cube0x0.github.io/Pocing-Beyond-DA/", + "https://adsecurity.org/?p=4064", + "https://github.com/gtworek/PSBits/tree/master/ServerLevelPluginDll" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "dll.code_signature.trusted", + "type": "boolean" + }, + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.category", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "file.code_signature.status", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": true, + "name": "process.executable", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "5d676480-9655-4507-adc6-4eec311efff8", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Privilege Escalation", + "Data Source: Elastic Defend", + "Data Source: Sysmon" + ], + "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": "eql", + "version": 1 + }, + "id": "5d676480-9655-4507-adc6-4eec311efff8_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/647fc812-7996-4795-8869-9c4ea595fe88_105.json b/packages/security_detection_engine/kibana/security_rule/647fc812-7996-4795-8869-9c4ea595fe88_105.json new file mode 100644 index 00000000000..9d29e67f791 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/647fc812-7996-4795-8869-9c4ea595fe88_105.json @@ -0,0 +1,74 @@ +{ + "attributes": { + "anomaly_threshold": 50, + "author": [ + "Elastic" + ], + "description": "Searches for rare processes running on multiple Linux hosts in an entire fleet or network. This reduces the detection of false positives since automated maintenance processes usually only run occasionally on a single machine but are common to all or many hosts in a fleet.", + "false_positives": [ + "A newly installed program or one that runs rarely as part of a monthly or quarterly workflow could trigger this alert." + ], + "from": "now-45m", + "interval": "15m", + "license": "Elastic License v2", + "machine_learning_job_id": [ + "v3_linux_anomalous_process_all_hosts" + ], + "name": "Anomalous Process For a Linux Population", + "note": "## Triage and analysis\n\n### Investigating Anomalous Process For a Linux Population\n\nSearching for abnormal Linux processes is a good methodology to find potentially malicious activity within a network. Understanding what is commonly run within an environment and developing baselines for legitimate activity can help uncover potential malware and suspicious behaviors.\n\nThis rule uses a machine learning job to detect a Linux process that is rare and unusual for all of the monitored Linux hosts in your fleet.\n\n#### Possible investigation steps\n\n- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, and whether they are located in expected locations.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Consider the user as identified by the `user.name` field. Is this program part of an expected workflow for the user who ran this program on this host?\n- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations.\n- Validate if the activity has a consistent cadence (for example, if it runs monthly or quarterly), as it could be part of a monthly or quarterly business process.\n- Examine the arguments and working directory of the process. These may provide indications as to the source of the program or the nature of the tasks it is performing.\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- 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 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- 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", + "references": [ + "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html" + ], + "related_integrations": [ + { + "package": "auditd_manager", + "version": "^1.0.0" + }, + { + "package": "endpoint", + "version": "^8.2.0" + } + ], + "risk_score": 21, + "rule_id": "647fc812-7996-4795-8869-9c4ea595fe88", + "setup": "## Setup\n\nThis rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:\n- Elastic Defend\n- Auditd Manager\n\n### Anomaly Detection Setup\n\nOnce the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the \"Definition\" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).\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 to your 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/current/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\n### Auditd Manager Integration Setup\nThe Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel.\nAuditd Manager 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.\n\n#### The following steps should be executed in order to add the Elastic Agent System integration \"auditd_manager\" to your system:\n- Go to the Kibana home page and click \u201cAdd integrations\u201d.\n- In the query bar, search for \u201cAuditd Manager\u201d and select the integration to see more details about it.\n- Click \u201cAdd Auditd Manager\u201d.\n- Configure the integration name and optionally add a description.\n- Review optional and advanced settings accordingly.\n- Add the newly installed \u201cauditd manager\u201d to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable.\n- Click \u201cSave and Continue\u201d.\n- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/auditd_manager).\n\n#### Rule Specific Setup Note\nAuditd Manager subscribes to the kernel and receives events as they occur without any additional configuration.\nHowever, 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.\n- For this detection rule no additional audit rules are required.\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Rule Type: ML", + "Rule Type: Machine Learning", + "Tactic: Persistence", + "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/" + } + ] + } + ] + } + ], + "type": "machine_learning", + "version": 105 + }, + "id": "647fc812-7996-4795-8869-9c4ea595fe88_105", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/696015ef-718e-40ff-ac4a-cc2ba88dbeeb_1.json b/packages/security_detection_engine/kibana/security_rule/696015ef-718e-40ff-ac4a-cc2ba88dbeeb_1.json new file mode 100644 index 00000000000..e182f223a9b --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/696015ef-718e-40ff-ac4a-cc2ba88dbeeb_1.json @@ -0,0 +1,87 @@ +{ + "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 programatic 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-10m", + "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 programatic 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-*\n| where event.provider == \"iam.amazonaws.com\" and event.action == \"CreateAccessKey\" and event.outcome == \"success\" and user.name != user.target.name\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": 1 + }, + "id": "696015ef-718e-40ff-ac4a-cc2ba88dbeeb_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/6d448b96-c922-4adb-b51c-b767f1ea5b76_109.json b/packages/security_detection_engine/kibana/security_rule/6d448b96-c922-4adb-b51c-b767f1ea5b76_109.json new file mode 100644 index 00000000000..87d4cfe3641 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/6d448b96-c922-4adb-b51c-b767f1ea5b76_109.json @@ -0,0 +1,74 @@ +{ + "attributes": { + "anomaly_threshold": 50, + "author": [ + "Elastic" + ], + "description": "Identifies rare processes that do not usually run on individual hosts, which can indicate execution of unauthorized services, malware, or persistence mechanisms. Processes are considered rare when they only run occasionally as compared with other processes running on the host.", + "false_positives": [ + "A newly installed program or one that runs rarely as part of a monthly or quarterly workflow could trigger this alert." + ], + "from": "now-45m", + "interval": "15m", + "license": "Elastic License v2", + "machine_learning_job_id": [ + "v3_rare_process_by_host_windows" + ], + "name": "Unusual Process For a Windows Host", + "note": "## Triage and analysis\n\n### Investigating Unusual Process For a Windows Host\n\nSearching for abnormal Windows processes is a good methodology to find potentially malicious activity within a network. Understanding what is commonly run within an environment and developing baselines for legitimate activity can help uncover potential malware and suspicious behaviors.\n\nThis rule uses a machine learning job to detect a Windows process that is rare and unusual for an individual Windows host in your environment.\n\n> **Note**:\n> This investigation guide uses the [Osquery Markdown Plugin](https://www.elastic.co/guide/en/security/master/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 - If the parent process is a legitimate system utility or service, this could be related to software updates or system management. If the parent process is something user-facing like an Office application, this process could be more suspicious.\n - Investigate the process metadata \u2014 such as the digital signature, directory, etc. \u2014 to obtain more context that can indicate whether the executable is associated with an expected software vendor or package.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Consider the user as identified by the `user.name` field. Is this program part of an expected workflow for the user who ran this program on this host?\n- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations.\n- Validate if the activity has a consistent cadence (for example, if it runs monthly or quarterly), as it could be part of a monthly or quarterly business process.\n- Examine the arguments and working directory of the process. These may provide indications as to the source of the program or the nature of the tasks it is performing.\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\":\"Retrieve Service Unisgned 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- 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- 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- Unusual Process For a Windows Host - 6d448b96-c922-4adb-b51c-b767f1ea5b76\n- Unusual Windows Path Activity - 445a342e-03fb-42d0-8656-0367eb2dead5\n- Unusual Windows Process Calling the Metadata Service - abae61a8-c560-4dbd-acca-1e1438bff36b\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- 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", + "references": [ + "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "windows", + "version": "^1.5.0" + } + ], + "risk_score": 21, + "rule_id": "6d448b96-c922-4adb-b51c-b767f1ea5b76", + "setup": "## Setup\n\nThis rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:\n- Elastic Defend\n- Windows\n\n### Anomaly Detection Setup\n\nOnce the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the \"Definition\" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).\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 to your 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/current/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\n### Windows Integration Setup\nThe Windows integration allows you to monitor the Windows OS, services, applications, and more.\n\n#### The following steps should be executed in order to add the Elastic Agent System integration \"windows\" to your system:\n- Go to the Kibana home page and click \u201cAdd integrations\u201d.\n- In the query bar, search for \u201cWindows\u201d and select the integration to see more details about it.\n- Click \u201cAdd Windows\u201d.\n- Configure the integration name and optionally add a description.\n- Review optional and advanced settings accordingly.\n- Add the newly installed \u201cwindows\u201d to an existing or a new agent policy, and deploy the agent on your system from which windows log files are desirable.\n- Click \u201cSave and Continue\u201d.\n- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/windows).\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Rule Type: ML", + "Rule Type: Machine Learning", + "Tactic: Persistence", + "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/" + } + ] + } + ] + } + ], + "type": "machine_learning", + "version": 109 + }, + "id": "6d448b96-c922-4adb-b51c-b767f1ea5b76_109", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/6e40d56f-5c0e-4ac6-aece-bee96645b172_106.json b/packages/security_detection_engine/kibana/security_rule/6e40d56f-5c0e-4ac6-aece-bee96645b172_106.json new file mode 100644 index 00000000000..6716545ece2 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/6e40d56f-5c0e-4ac6-aece-bee96645b172_106.json @@ -0,0 +1,89 @@ +{ + "attributes": { + "anomaly_threshold": 50, + "author": [ + "Elastic" + ], + "description": "Searches for rare processes running on multiple hosts in an entire fleet or network. This reduces the detection of false positives since automated maintenance processes usually only run occasionally on a single machine but are common to all or many hosts in a fleet.", + "false_positives": [ + "A newly installed program or one that runs rarely as part of a monthly or quarterly workflow could trigger this alert." + ], + "from": "now-45m", + "interval": "15m", + "license": "Elastic License v2", + "machine_learning_job_id": [ + "v3_windows_anomalous_process_all_hosts" + ], + "name": "Anomalous Process For a Windows Population", + "note": "## Triage and analysis\n\n### Investigating Anomalous Process For a Windows Population\n\nSearching for abnormal Windows processes is a good methodology to find potentially malicious activity within a network. Understanding what is commonly run within an environment and developing baselines for legitimate activity can help uncover potential malware and suspicious behaviors.\n\nThis rule uses a machine learning job to detect a Windows process that is rare and unusual for all of the monitored Windows hosts in your environment.\n\n> **Note**:\n> This investigation guide uses the [Osquery Markdown Plugin](https://www.elastic.co/guide/en/security/master/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 - If the parent process is a legitimate system utility or service, this could be related to software updates or system management. If the parent process is something user-facing like an Office application, this process could be more suspicious.\n - Investigate the process metadata \u2014 such as the digital signature, directory, etc. \u2014 to obtain more context that can indicate whether the executable is associated with an expected software vendor or package.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Consider the user as identified by the `user.name` field. Is this program part of an expected workflow for the user who ran this program on this host?\n- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations.\n- Validate if the activity has a consistent cadence (for example, if it runs monthly or quarterly), as it could be part of a monthly or quarterly business process.\n- Examine the arguments and working directory of the process. These may provide indications as to the source of the program or the nature of the tasks it is performing.\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 '%LocalSyste' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR\\nuser_account == null)\\n\"}}\n - !{osquery{\"label\":\"Retrieve Service Unisgned 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- 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- 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- Unusual Process For a Windows Host - 6d448b96-c922-4adb-b51c-b767f1ea5b76\n- Unusual Windows Path Activity - 445a342e-03fb-42d0-8656-0367eb2dead5\n- Unusual Windows Process Calling the Metadata Service - abae61a8-c560-4dbd-acca-1e1438bff36b\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- 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", + "references": [ + "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "windows", + "version": "^1.5.0" + } + ], + "risk_score": 21, + "rule_id": "6e40d56f-5c0e-4ac6-aece-bee96645b172", + "setup": "## Setup\n\nThis rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:\n- Elastic Defend\n- Windows\n\n### Anomaly Detection Setup\n\nOnce the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the \"Definition\" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).\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 to your 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/current/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\n### Windows Integration Setup\nThe Windows integration allows you to monitor the Windows OS, services, applications, and more.\n\n#### The following steps should be executed in order to add the Elastic Agent System integration \"windows\" to your system:\n- Go to the Kibana home page and click \u201cAdd integrations\u201d.\n- In the query bar, search for \u201cWindows\u201d and select the integration to see more details about it.\n- Click \u201cAdd Windows\u201d.\n- Configure the integration name and optionally add a description.\n- Review optional and advanced settings accordingly.\n- Add the newly installed \u201cwindows\u201d to an existing or a new agent policy, and deploy the agent on your system from which windows log files are desirable.\n- Click \u201cSave and Continue\u201d.\n- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/windows).\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Rule Type: ML", + "Rule Type: Machine Learning", + "Tactic: Persistence", + "Tactic: Execution" + ], + "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": "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/" + } + ] + } + ] + } + ], + "type": "machine_learning", + "version": 106 + }, + "id": "6e40d56f-5c0e-4ac6-aece-bee96645b172_106", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/745b0119-0560-43ba-860a-7235dd8cee8d_105.json b/packages/security_detection_engine/kibana/security_rule/745b0119-0560-43ba-860a-7235dd8cee8d_105.json new file mode 100644 index 00000000000..a8551cc3f41 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/745b0119-0560-43ba-860a-7235dd8cee8d_105.json @@ -0,0 +1,68 @@ +{ + "attributes": { + "anomaly_threshold": 75, + "author": [ + "Elastic" + ], + "description": "A machine learning job detected a user logging in at a time of day that is unusual for the user. This can be due to credentialed access via a compromised account when the user and the threat actor are in different time zones. In addition, unauthorized user activity often takes place during non-business hours.", + "false_positives": [ + "Users working late, or logging in from unusual time zones while traveling, may trigger this rule." + ], + "from": "now-30m", + "interval": "15m", + "license": "Elastic License v2", + "machine_learning_job_id": "auth_rare_hour_for_a_user", + "name": "Unusual Hour for a User to Logon", + "note": "## Triage and analysis\n\n### Investigating Unusual Hour for a User to Logon\n\nThis rule uses a machine learning job to detect a user logging in at a time of day that is unusual for the user. This can be due to credentialed access via a compromised account when the user and the threat actor are in different time zones. It can also indicate unauthorized user activity, as it often occurs during non-business hours.\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 any abnormal account behavior, such as command executions, file creations or modifications, network connections, data access, and logon events.\n- Investigate other alerts associated with the involved users during the past 48 hours.\n\n### False positive analysis\n\n- Users may need to log in during non-business hours to perform work-related tasks. Examine whether the company policies authorize this or if the activity is done under change management.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the 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- 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", + "references": [ + "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html" + ], + "related_integrations": [ + { + "package": "auditd_manager", + "version": "^1.0.0" + }, + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "system", + "version": "^1.6.4" + } + ], + "risk_score": 21, + "rule_id": "745b0119-0560-43ba-860a-7235dd8cee8d", + "setup": "## Setup\n\nThis rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:\n- Elastic Defend\n- Auditd Manager\n- System\n\n### Anomaly Detection Setup\n\nOnce the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the \"Definition\" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).\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 to your 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/current/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\n### Auditd Manager Integration Setup\nThe Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel.\nAuditd Manager 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.\n\n#### The following steps should be executed in order to add the Elastic Agent System integration \"auditd_manager\" to your system:\n- Go to the Kibana home page and click \u201cAdd integrations\u201d.\n- In the query bar, search for \u201cAuditd Manager\u201d and select the integration to see more details about it.\n- Click \u201cAdd Auditd Manager\u201d.\n- Configure the integration name and optionally add a description.\n- Review optional and advanced settings accordingly.\n- Add the newly installed \u201cauditd manager\u201d to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable.\n- Click \u201cSave and Continue\u201d.\n- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/auditd_manager).\n\n#### Rule Specific Setup Note\nAuditd Manager subscribes to the kernel and receives events as they occur without any additional configuration.\nHowever, 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.\n- For this detection rule no additional audit rules are required.\n\n### System Integration Setup\nThe System integration allows you to collect system logs and metrics from your servers with Elastic Agent.\n\n#### The following steps should be executed in order to add the Elastic Agent System integration \"system\" to your system:\n- Go to the Kibana home page and click \u201cAdd integrations\u201d.\n- In the query bar, search for \u201cSystem\u201d and select the integration to see more details about it.\n- Click \u201cAdd System\u201d.\n- Configure the integration name and optionally add a description.\n- Review optional and advanced settings accordingly.\n- Add the newly installed \u201csystem\u201d to an existing or a new agent policy, and deploy the agent on your system from which system log files are desirable.\n- Click \u201cSave and Continue\u201d.\n- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/system).\n", + "severity": "low", + "tags": [ + "Use Case: Identity and Access Audit", + "Use Case: Threat Detection", + "Rule Type: ML", + "Rule Type: Machine Learning", + "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/" + } + ] + } + ], + "type": "machine_learning", + "version": 105 + }, + "id": "745b0119-0560-43ba-860a-7235dd8cee8d_105", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/746edc4c-c54c-49c6-97a1-651223819448_104.json b/packages/security_detection_engine/kibana/security_rule/746edc4c-c54c-49c6-97a1-651223819448_104.json new file mode 100644 index 00000000000..902c08c0f9b --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/746edc4c-c54c-49c6-97a1-651223819448_104.json @@ -0,0 +1,68 @@ +{ + "attributes": { + "anomaly_threshold": 50, + "author": [ + "Elastic" + ], + "description": "A machine learning job detected a rare and unusual DNS query that indicate network activity with unusual DNS domains. This can be due to initial access, persistence, command-and-control, or exfiltration activity. For example, when a user clicks on a link in a phishing email or opens a malicious document, a request may be sent to download and run a payload from an uncommon domain. When malware is already running, it may send requests to an uncommon DNS domain the malware uses for command-and-control communication.", + "false_positives": [ + "A newly installed program or one that runs rarely as part of a monthly or quarterly workflow could trigger this alert. Network activity that occurs rarely, in small quantities, can trigger this alert. Possible examples are browsing technical support or vendor networks sparsely. A user who visits a new or unique web destination may trigger this alert." + ], + "from": "now-45m", + "interval": "15m", + "license": "Elastic License v2", + "machine_learning_job_id": "packetbeat_rare_dns_question", + "name": "Unusual DNS Activity", + "references": [ + "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "network_traffic", + "version": "^1.1.0" + } + ], + "risk_score": 21, + "rule_id": "746edc4c-c54c-49c6-97a1-651223819448", + "setup": "## Setup\n\nThis rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:\n- Elastic Defend\n- Network Packet Capture\n\n### Anomaly Detection Setup\n\nOnce the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the \"Definition\" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).\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 to your 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/current/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\n### Network Packet Capture Integration Setup\nThe Network Packet Capture integration sniffs network packets on a host and dissects known protocols. Monitoring the network traffic is critical to gaining observability and securing your environment \u2014 ensuring high levels of performance and security. The Network Packet Capture integration captures the network traffic between your application servers, decodes common application layer protocols and records the interesting fields for each transaction.\n\n#### The following steps should be executed in order to add the Elastic Agent System integration \"network_traffic\" to your system:\n- Go to the Kibana home page and click \u201cAdd integrations\u201d.\n- In the query bar, search for \u201cNetwork Packet Capture\u201d and select the integration to see more details about it.\n- Click \u201cAdd Network Packet Capture\u201d.\n- Configure the integration name and optionally add a description.\n- Review optional and advanced settings accordingly.\n- Add the newly installed \u201cnetwork_traffic\u201d to an existing or a new agent policy, and deploy the agent on your system from which network log files are desirable.\n- Click \u201cSave and Continue\u201d.\n- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/network_traffic).\n", + "severity": "low", + "tags": [ + "Use Case: Threat Detection", + "Rule Type: ML", + "Rule Type: Machine Learning", + "Tactic: Command and Control" + ], + "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.004", + "name": "DNS", + "reference": "https://attack.mitre.org/techniques/T1071/004/" + } + ] + } + ] + } + ], + "type": "machine_learning", + "version": 104 + }, + "id": "746edc4c-c54c-49c6-97a1-651223819448_104", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/78d3d8d9-b476-451d-a9e0-7a5addd70670_209.json b/packages/security_detection_engine/kibana/security_rule/78d3d8d9-b476-451d-a9e0-7a5addd70670_209.json new file mode 100644 index 00000000000..b34747a54e9 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/78d3d8d9-b476-451d-a9e0-7a5addd70670_209.json @@ -0,0 +1,43 @@ +{ + "attributes": { + "anomaly_threshold": 50, + "author": [ + "Elastic" + ], + "description": "A machine learning job detected a significant spike in the rate of a particular error in the CloudTrail messages. Spikes in error messages may accompany attempts at privilege escalation, lateral movement, or discovery.", + "false_positives": [ + "Spikes in error message activity can also be due to bugs in cloud automation scripts or workflows; changes to cloud automation scripts or workflows; adoption of new services; changes in the way services are used; or changes to IAM privileges." + ], + "from": "now-60m", + "interval": "15m", + "license": "Elastic License v2", + "machine_learning_job_id": "high_distinct_count_error_message", + "name": "Spike in AWS Error Messages", + "note": "## Triage and analysis\n\n### Investigating Spike in AWS Error Messages\n\nCloudTrail logging provides visibility on actions taken within an AWS environment. By monitoring these events and understanding what is considered normal behavior within an organization, you can spot suspicious or malicious activity when deviations occur.\n\nThis rule uses a machine learning job to detect a significant spike in the rate of a particular error in the CloudTrail messages. Spikes in error messages may accompany attempts at privilege escalation, lateral movement, or discovery.\n\n#### Possible investigation steps\n\n- Examine the history of the error. If the error only manifested recently, it might be related to recent changes in an automation module or script. You can find the error in the `aws.cloudtrail.error_code field` field.\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- Examine the history of the command. If the command only manifested recently, it might be part of a new automation module or script. If it has a consistent cadence (for example, it appears in small numbers on a weekly or monthly cadence), it might be part of a housekeeping or maintenance process. You can find the command in the `event.action field` field.\n- The adoption of new services or the addition of new functionality to scripts may generate false positives.\n\n### Related Rules\n\n- Unusual City For an AWS Command - 809b70d3-e2c3-455e-af1b-2626a5a1a276\n- Unusual Country For an AWS Command - dca28dee-c999-400f-b640-50a081cc0fd1\n- Unusual AWS Command for a User - ac706eae-d5ec-4b14-b4fd-e8ba8086f0e1\n- Rare AWS Error Code - 19de8096-e2b0-4bd8-80c9-34a820813fff\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", + "references": [ + "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html" + ], + "related_integrations": [ + { + "package": "aws", + "version": "^2.0.0" + } + ], + "risk_score": 21, + "rule_id": "78d3d8d9-b476-451d-a9e0-7a5addd70670", + "setup": "## Setup\n\nThis rule requires the installation of associated Machine Learning jobs, as well as data coming in from AWS.\n\n### Anomaly Detection Setup\n\nOnce the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the \"Definition\" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).\n\n### AWS Integration Setup\nThe AWS integration allows you to collect logs and metrics from Amazon Web Services (AWS) with Elastic Agent.\n\n#### The following steps should be executed in order to add the Elastic Agent System integration \"aws\" to your system:\n- Go to the Kibana home page and click \u201cAdd integrations\u201d.\n- In the query bar, search for \u201cAWS\u201d and select the integration to see more details about it.\n- Click \u201cAdd AWS\u201d.\n- Configure the integration name and optionally add a description.\n- Review optional and advanced settings accordingly.\n- Add the newly installed \u201caws\u201d to an existing or a new agent policy, and deploy the agent on your system from which aws log files are desirable.\n- Click \u201cSave and Continue\u201d.\n- For more details on the integration refer to the [helper guide](https://www.elastic.co/docs/current/integrations/aws).\n", + "severity": "low", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Rule Type: ML", + "Rule Type: Machine Learning", + "Resources: Investigation Guide" + ], + "type": "machine_learning", + "version": 209 + }, + "id": "78d3d8d9-b476-451d-a9e0-7a5addd70670_209", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/809b70d3-e2c3-455e-af1b-2626a5a1a276_209.json b/packages/security_detection_engine/kibana/security_rule/809b70d3-e2c3-455e-af1b-2626a5a1a276_209.json new file mode 100644 index 00000000000..8c13558664f --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/809b70d3-e2c3-455e-af1b-2626a5a1a276_209.json @@ -0,0 +1,43 @@ +{ + "attributes": { + "anomaly_threshold": 50, + "author": [ + "Elastic" + ], + "description": "A machine learning job detected AWS command activity that, while not inherently suspicious or abnormal, is sourcing from a geolocation (city) that is unusual for the command. This can be the result of compromised credentials or keys being used by a threat actor in a different geography than the authorized user(s).", + "false_positives": [ + "New or unusual command and user geolocation activity can be due to manual troubleshooting or reconfiguration; changes in cloud automation scripts or workflows; adoption of new services; expansion into new regions; increased adoption of work from home policies; or users who travel frequently." + ], + "from": "now-2h", + "interval": "15m", + "license": "Elastic License v2", + "machine_learning_job_id": "rare_method_for_a_city", + "name": "Unusual City For an AWS Command", + "note": "## Triage and analysis\n\n### Investigating Unusual City For an AWS Command\n\nCloudTrail logging provides visibility on actions taken within an AWS environment. By monitoring these events and understanding what is considered normal behavior within an organization, you can spot suspicious or malicious activity when deviations occur.\n\nThis rule uses a machine learning job to detect an AWS API command that while not inherently suspicious or abnormal, is sourcing from a geolocation (city) that is unusual for the command. This can be the result of compromised credentials or keys used by a threat actor in a different geography than the authorized user(s).\n\nDetection alerts from this rule indicate an AWS API command or method call that is rare and unusual for the geolocation of the source IP address.\n\n#### Possible investigation steps\n\n- Identify the user account involved and the action performed. Verify whether it should perform this kind of action.\n - Examine the user identity in the `aws.cloudtrail.user_identity.arn` field and the access key ID in the `aws.cloudtrail.user_identity.access_key_id` field, which can help identify the precise user context.\n - The user agent details in the `user_agent.original` field may also indicate what kind of a client made the request.\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 might indicate the source of the program or the nature of its tasks.\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- False positives can occur if activity is coming from new employees based in a city with no previous history in AWS.\n- Examine the history of the command. If the command only manifested recently, it might be part of a new automation module or script. If it has a consistent cadence (for example, it appears in small numbers on a weekly or monthly cadence), it might be part of a housekeeping or maintenance process. You can find the command in the `event.action field` field.\n\n### Related Rules\n\n- Unusual Country For an AWS Command - dca28dee-c999-400f-b640-50a081cc0fd1\n- Unusual AWS Command for a User - ac706eae-d5ec-4b14-b4fd-e8ba8086f0e1\n- Rare AWS Error Code - 19de8096-e2b0-4bd8-80c9-34a820813fff\n- Spike in AWS Error Messages - 78d3d8d9-b476-451d-a9e0-7a5addd70670\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", + "references": [ + "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html" + ], + "related_integrations": [ + { + "package": "aws", + "version": "^2.0.0" + } + ], + "risk_score": 21, + "rule_id": "809b70d3-e2c3-455e-af1b-2626a5a1a276", + "setup": "## Setup\n\nThis rule requires the installation of associated Machine Learning jobs, as well as data coming in from AWS.\n\n### Anomaly Detection Setup\n\nOnce the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the \"Definition\" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).\n\n### AWS Integration Setup\nThe AWS integration allows you to collect logs and metrics from Amazon Web Services (AWS) with Elastic Agent.\n\n#### The following steps should be executed in order to add the Elastic Agent System integration \"aws\" to your system:\n- Go to the Kibana home page and click \u201cAdd integrations\u201d.\n- In the query bar, search for \u201cAWS\u201d and select the integration to see more details about it.\n- Click \u201cAdd AWS\u201d.\n- Configure the integration name and optionally add a description.\n- Review optional and advanced settings accordingly.\n- Add the newly installed \u201caws\u201d to an existing or a new agent policy, and deploy the agent on your system from which aws log files are desirable.\n- Click \u201cSave and Continue\u201d.\n- For more details on the integration refer to the [helper guide](https://www.elastic.co/docs/current/integrations/aws).\n", + "severity": "low", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Rule Type: ML", + "Rule Type: Machine Learning", + "Resources: Investigation Guide" + ], + "type": "machine_learning", + "version": 209 + }, + "id": "809b70d3-e2c3-455e-af1b-2626a5a1a276_209", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/894326d2-56c0-4342-b553-4abfaf421b5b_1.json b/packages/security_detection_engine/kibana/security_rule/894326d2-56c0-4342-b553-4abfaf421b5b_1.json new file mode 100644 index 00000000000..2bcbd453ca5 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/894326d2-56c0-4342-b553-4abfaf421b5b_1.json @@ -0,0 +1,88 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies the creation of a DNS record that is potentially meant to enable WPAD spoofing. Attackers can disable the Global Query Block List (GQBL) and create a \"wpad\" record to exploit hosts running WPAD with default settings for privilege escalation and lateral movement.", + "from": "now-9m", + "index": [ + "winlogbeat-*", + "logs-system.*", + "logs-windows.*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Potential WPAD Spoofing via DNS Record Creation", + "query": "any where host.os.type == \"windows\" and event.action == \"Directory Service Changes\" and\n event.code == \"5137\" and winlog.event_data.ObjectDN : \"DC=wpad,*\"\n", + "references": [ + "https://www.thehacker.recipes/ad/movement/mitm-and-coerced-authentications/wpad-spoofing#through-adidns-spoofing", + "https://cube0x0.github.io/Pocing-Beyond-DA/" + ], + "related_integrations": [ + { + "package": "system", + "version": "^1.6.4" + }, + { + "package": "windows", + "version": "^1.5.0" + } + ], + "required_fields": [ + { + "ecs": true, + "name": "event.action", + "type": "keyword" + }, + { + "ecs": true, + "name": "event.code", + "type": "keyword" + }, + { + "ecs": true, + "name": "host.os.type", + "type": "keyword" + }, + { + "ecs": false, + "name": "winlog.event_data.ObjectDN", + "type": "unknown" + } + ], + "risk_score": 47, + "rule_id": "894326d2-56c0-4342-b553-4abfaf421b5b", + "setup": "## Setup\n\nThe 'Audit Directory Service Changes' logging policy must be configured for (Success, Failure).\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 >\nDS Access >\nAudit Directory Service Changes (Success,Failure)\n```\n\nThe above policy does not cover the target object by default (we still need it to be configured to generate events), so we need to set up an AuditRule using https://github.com/OTRF/Set-AuditRule.\n\n```\nSet-AuditRule -AdObjectPath 'AD:\\CN=MicrosoftDNS,DC=DomainDNSZones,DC=Domain,DC=com' -WellKnownSidType WorldSid -Rights CreateChild -InheritanceFlags Descendents -AttributeGUID e0fa1e8c-9b45-11d0-afdd-00c04fd930c9 -AuditFlags Success\n```\n", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Credential Access", + "Data Source: Active Directory", + "Use Case: Active Directory Monitoring" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0006", + "name": "Credential Access", + "reference": "https://attack.mitre.org/tactics/TA0006/" + }, + "technique": [ + { + "id": "T1557", + "name": "Adversary-in-the-Middle", + "reference": "https://attack.mitre.org/techniques/T1557/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 1 + }, + "id": "894326d2-56c0-4342-b553-4abfaf421b5b_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/91f02f01-969f-4167-8d77-07827ac4cee0_104.json b/packages/security_detection_engine/kibana/security_rule/91f02f01-969f-4167-8d77-07827ac4cee0_104.json new file mode 100644 index 00000000000..1d606a007b7 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/91f02f01-969f-4167-8d77-07827ac4cee0_104.json @@ -0,0 +1,68 @@ +{ + "attributes": { + "anomaly_threshold": 50, + "author": [ + "Elastic" + ], + "description": "A machine learning job detected a rare and unusual user agent indicating web browsing activity by an unusual process other than a web browser. This can be due to persistence, command-and-control, or exfiltration activity. Uncommon user agents coming from remote sources to local destinations are often the result of scanners, bots, and web scrapers, which are part of common Internet background traffic. Much of this is noise, but more targeted attacks on websites using tools like Burp or SQLmap can sometimes be discovered by spotting uncommon user agents. Uncommon user agents in traffic from local sources to remote destinations can be any number of things, including harmless programs like weather monitoring or stock-trading programs. However, uncommon user agents from local sources can also be due to malware or scanning activity.", + "false_positives": [ + "Web activity that is uncommon, like security scans, may trigger this alert and may need to be excluded. A new or rarely used program that calls web services may trigger this alert." + ], + "from": "now-45m", + "interval": "15m", + "license": "Elastic License v2", + "machine_learning_job_id": "packetbeat_rare_user_agent", + "name": "Unusual Web User Agent", + "references": [ + "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "network_traffic", + "version": "^1.1.0" + } + ], + "risk_score": 21, + "rule_id": "91f02f01-969f-4167-8d77-07827ac4cee0", + "setup": "## Setup\n\nThis rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:\n- Elastic Defend\n- Network Packet Capture\n\n### Anomaly Detection Setup\n\nOnce the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the \"Definition\" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).\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 to your 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/current/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\n### Network Packet Capture Integration Setup\nThe Network Packet Capture integration sniffs network packets on a host and dissects known protocols. Monitoring the network traffic is critical to gaining observability and securing your environment \u2014 ensuring high levels of performance and security. The Network Packet Capture integration captures the network traffic between your application servers, decodes common application layer protocols and records the interesting fields for each transaction.\n\n#### The following steps should be executed in order to add the Elastic Agent System integration \"network_traffic\" to your system:\n- Go to the Kibana home page and click \u201cAdd integrations\u201d.\n- In the query bar, search for \u201cNetwork Packet Capture\u201d and select the integration to see more details about it.\n- Click \u201cAdd Network Packet Capture\u201d.\n- Configure the integration name and optionally add a description.\n- Review optional and advanced settings accordingly.\n- Add the newly installed \u201cnetwork_traffic\u201d to an existing or a new agent policy, and deploy the agent on your system from which network log files are desirable.\n- Click \u201cSave and Continue\u201d.\n- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/network_traffic).\n", + "severity": "low", + "tags": [ + "Use Case: Threat Detection", + "Rule Type: ML", + "Rule Type: Machine Learning", + "Tactic: Command and Control" + ], + "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/" + } + ] + } + ] + } + ], + "type": "machine_learning", + "version": 104 + }, + "id": "91f02f01-969f-4167-8d77-07827ac4cee0_104", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/91f02f01-969f-4167-8f55-07827ac3acc9_104.json b/packages/security_detection_engine/kibana/security_rule/91f02f01-969f-4167-8f55-07827ac3acc9_104.json new file mode 100644 index 00000000000..3c7474b5af3 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/91f02f01-969f-4167-8f55-07827ac3acc9_104.json @@ -0,0 +1,68 @@ +{ + "attributes": { + "anomaly_threshold": 50, + "author": [ + "Elastic" + ], + "description": "A machine learning job detected a rare and unusual URL that indicates unusual web browsing activity. This can be due to initial access, persistence, command-and-control, or exfiltration activity. For example, in a strategic web compromise or watering hole attack, when a trusted website is compromised to target a particular sector or organization, targeted users may receive emails with uncommon URLs for trusted websites. These URLs can be used to download and run a payload. When malware is already running, it may send requests to uncommon URLs on trusted websites the malware uses for command-and-control communication. When rare URLs are observed being requested for a local web server by a remote source, these can be due to web scanning, enumeration or attack traffic, or they can be due to bots and web scrapers which are part of common Internet background traffic.", + "false_positives": [ + "Web activity that occurs rarely in small quantities can trigger this alert. Possible examples are browsing technical support or vendor URLs that are used very sparsely. A user who visits a new and unique web destination may trigger this alert when the activity is sparse. Web applications that generate URLs unique to a transaction may trigger this when they are used sparsely. Web domains can be excluded in cases such as these." + ], + "from": "now-45m", + "interval": "15m", + "license": "Elastic License v2", + "machine_learning_job_id": "packetbeat_rare_urls", + "name": "Unusual Web Request", + "references": [ + "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "network_traffic", + "version": "^1.1.0" + } + ], + "risk_score": 21, + "rule_id": "91f02f01-969f-4167-8f55-07827ac3acc9", + "setup": "## Setup\n\nThis rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:\n- Elastic Defend\n- Network Packet Capture\n\n### Anomaly Detection Setup\n\nOnce the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the \"Definition\" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).\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 to your 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/current/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\n### Network Packet Capture Integration Setup\nThe Network Packet Capture integration sniffs network packets on a host and dissects known protocols. Monitoring the network traffic is critical to gaining observability and securing your environment \u2014 ensuring high levels of performance and security. The Network Packet Capture integration captures the network traffic between your application servers, decodes common application layer protocols and records the interesting fields for each transaction.\n\n#### The following steps should be executed in order to add the Elastic Agent System integration \"network_traffic\" to your system:\n- Go to the Kibana home page and click \u201cAdd integrations\u201d.\n- In the query bar, search for \u201cNetwork Packet Capture\u201d and select the integration to see more details about it.\n- Click \u201cAdd Network Packet Capture\u201d.\n- Configure the integration name and optionally add a description.\n- Review optional and advanced settings accordingly.\n- Add the newly installed \u201cnetwork_traffic\u201d to an existing or a new agent policy, and deploy the agent on your system from which network log files are desirable.\n- Click \u201cSave and Continue\u201d.\n- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/network_traffic).\n", + "severity": "low", + "tags": [ + "Use Case: Threat Detection", + "Rule Type: ML", + "Rule Type: Machine Learning", + "Tactic: Command and Control" + ], + "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/" + } + ] + } + ] + } + ], + "type": "machine_learning", + "version": 104 + }, + "id": "91f02f01-969f-4167-8f55-07827ac3acc9_104", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/91f02f01-969f-4167-8f66-07827ac3bdd9_104.json b/packages/security_detection_engine/kibana/security_rule/91f02f01-969f-4167-8f66-07827ac3bdd9_104.json new file mode 100644 index 00000000000..4322895dac0 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/91f02f01-969f-4167-8f66-07827ac3bdd9_104.json @@ -0,0 +1,61 @@ +{ + "attributes": { + "anomaly_threshold": 50, + "author": [ + "Elastic" + ], + "description": "A machine learning job detected unusually large numbers of DNS queries for a single top-level DNS domain, which is often used for DNS tunneling. DNS tunneling can be used for command-and-control, persistence, or data exfiltration activity. For example, dnscat tends to generate many DNS questions for a top-level domain as it uses the DNS protocol to tunnel data.", + "false_positives": [ + "DNS domains that use large numbers of child domains, such as software or content distribution networks, can trigger this alert and such parent domains can be excluded." + ], + "from": "now-45m", + "interval": "15m", + "license": "Elastic License v2", + "machine_learning_job_id": "packetbeat_dns_tunneling", + "name": "DNS Tunneling", + "references": [ + "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "network_traffic", + "version": "^1.1.0" + } + ], + "risk_score": 21, + "rule_id": "91f02f01-969f-4167-8f66-07827ac3bdd9", + "setup": "## Setup\n\nThis rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:\n- Elastic Defend\n- Network Packet Capture\n\n### Anomaly Detection Setup\n\nOnce the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the \"Definition\" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).\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 to your 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/current/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\n### Network Packet Capture Integration Setup\nThe Network Packet Capture integration sniffs network packets on a host and dissects known protocols. Monitoring the network traffic is critical to gaining observability and securing your environment \u2014 ensuring high levels of performance and security. The Network Packet Capture integration captures the network traffic between your application servers, decodes common application layer protocols and records the interesting fields for each transaction.\n\n#### The following steps should be executed in order to add the Elastic Agent System integration \"network_traffic\" to your system:\n- Go to the Kibana home page and click \u201cAdd integrations\u201d.\n- In the query bar, search for \u201cNetwork Packet Capture\u201d and select the integration to see more details about it.\n- Click \u201cAdd Network Packet Capture\u201d.\n- Configure the integration name and optionally add a description.\n- Review optional and advanced settings accordingly.\n- Add the newly installed \u201cnetwork_traffic\u201d to an existing or a new agent policy, and deploy the agent on your system from which network log files are desirable.\n- Click \u201cSave and Continue\u201d.\n- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/network_traffic).\n", + "severity": "low", + "tags": [ + "Use Case: Threat Detection", + "Rule Type: ML", + "Rule Type: Machine Learning", + "Tactic: Command and Control" + ], + "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/" + } + ] + } + ], + "type": "machine_learning", + "version": 104 + }, + "id": "91f02f01-969f-4167-8f66-07827ac3bdd9_104", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/93075852-b0f5-4b8b-89c3-a226efae5726_207.json b/packages/security_detection_engine/kibana/security_rule/93075852-b0f5-4b8b-89c3-a226efae5726_207.json new file mode 100644 index 00000000000..7673981297e --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/93075852-b0f5-4b8b-89c3-a226efae5726_207.json @@ -0,0 +1,113 @@ +{ + "attributes": { + "author": [ + "Austin Songer" + ], + "description": "Identifies the use of AssumeRole. AssumeRole returns a set of temporary security credentials that can be used to access AWS resources. An adversary could use those credentials to move laterally and escalate privileges.", + "false_positives": [ + "Automated processes that use Terraform may lead to false positives." + ], + "index": [ + "filebeat-*", + "logs-aws.cloudtrail-*" + ], + "language": "kuery", + "license": "Elastic License v2", + "name": "AWS Security Token Service (STS) AssumeRole Usage", + "note": "", + "query": "event.dataset:aws.cloudtrail and event.provider:sts.amazonaws.com and event.action:AssumeRole and\naws.cloudtrail.user_identity.session_context.session_issuer.type:Role and event.outcome:success\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.session_context.session_issuer.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", + "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 STS", + "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": "query", + "version": 207 + }, + "id": "93075852-b0f5-4b8b-89c3-a226efae5726_207", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/94e734c0-2cda-11ef-84e1-f661ea17fbce_1.json b/packages/security_detection_engine/kibana/security_rule/94e734c0-2cda-11ef-84e1-f661ea17fbce_1.json new file mode 100644 index 00000000000..bb2fffb1cc5 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/94e734c0-2cda-11ef-84e1-f661ea17fbce_1.json @@ -0,0 +1,75 @@ +{ + "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| 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/" + ], + "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": 1 + }, + "id": "94e734c0-2cda-11ef-84e1-f661ea17fbce_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/95b99adc-2cda-11ef-84e1-f661ea17fbce_1.json b/packages/security_detection_engine/kibana/security_rule/95b99adc-2cda-11ef-84e1-f661ea17fbce_1.json new file mode 100644 index 00000000000..5e7b2e18651 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/95b99adc-2cda-11ef-84e1-f661ea17fbce_1.json @@ -0,0 +1,75 @@ +{ + "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| 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/" + ], + "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": 1 + }, + "id": "95b99adc-2cda-11ef-84e1-f661ea17fbce_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/99dcf974-6587-4f65-9252-d866a3fdfd9c_105.json b/packages/security_detection_engine/kibana/security_rule/99dcf974-6587-4f65-9252-d866a3fdfd9c_105.json new file mode 100644 index 00000000000..6deff05823e --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/99dcf974-6587-4f65-9252-d866a3fdfd9c_105.json @@ -0,0 +1,68 @@ +{ + "attributes": { + "anomaly_threshold": 75, + "author": [ + "Elastic" + ], + "description": "A machine learning job found an unusually large spike in authentication failure events. This can be due to password spraying, user enumeration or brute force activity and may be a precursor to account takeover or credentialed access.", + "false_positives": [ + "A misconfigured service account can trigger this alert. A password change on an account used by an email client can trigger this alert. Security test cycles that include brute force or password spraying activities may trigger this alert." + ], + "from": "now-30m", + "interval": "15m", + "license": "Elastic License v2", + "machine_learning_job_id": "auth_high_count_logon_fails", + "name": "Spike in Failed Logon Events", + "note": "## Triage and analysis\n\n### Investigating Spike in Failed Logon Events\n\nThis rule uses a machine learning job to detect a substantial spike in failed authentication events. This could indicate attempts to enumerate users, password spraying, brute force, etc.\n\n#### Possible investigation steps\n\n- Identify the users involved and if the activity targets a specific user or a set of users.\n- Check if the authentication comes from different sources.\n- Investigate if the host where the failed authentication events occur is exposed to the internet.\n - If the host is exposed to the internet, and the source of these attempts is external, the activity can be related to bot activity and possibly not directed at your organization.\n - If the host is not exposed to the internet, investigate the hosts where the authentication attempts are coming from, as this can indicate that they are compromised and the attacker is trying to move laterally.\n- Investigate other alerts associated with the involved users and hosts during the past 48 hours.\n- Check whether the involved credentials are used in automation or scheduled tasks.\n- If this activity is suspicious, contact the account owner and confirm whether they are aware of it.\n- Investigate whether there are successful authentication events from the involved sources. This could indicate a successful brute force or password spraying attack.\n\n### False positive analysis\n\n- If the account is used in automation tasks, it is possible that they are using expired credentials, causing a spike in authentication failures.\n- Authentication failures can be related to permission issues.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the 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- Assess whether the asset should be exposed to the internet, and take action to reduce your attack surface.\n - If the asset needs to be exposed to the internet, restrict access to remote login services to specific IPs.\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", + "references": [ + "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html" + ], + "related_integrations": [ + { + "package": "auditd_manager", + "version": "^1.0.0" + }, + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "system", + "version": "^1.6.4" + } + ], + "risk_score": 21, + "rule_id": "99dcf974-6587-4f65-9252-d866a3fdfd9c", + "setup": "## Setup\n\nThis rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:\n- Elastic Defend\n- Auditd Manager\n- System\n\n### Anomaly Detection Setup\n\nOnce the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the \"Definition\" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).\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 to your 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/current/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\n### Auditd Manager Integration Setup\nThe Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel.\nAuditd Manager 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.\n\n#### The following steps should be executed in order to add the Elastic Agent System integration \"auditd_manager\" to your system:\n- Go to the Kibana home page and click \u201cAdd integrations\u201d.\n- In the query bar, search for \u201cAuditd Manager\u201d and select the integration to see more details about it.\n- Click \u201cAdd Auditd Manager\u201d.\n- Configure the integration name and optionally add a description.\n- Review optional and advanced settings accordingly.\n- Add the newly installed \u201cauditd manager\u201d to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable.\n- Click \u201cSave and Continue\u201d.\n- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/auditd_manager).\n\n#### Rule Specific Setup Note\nAuditd Manager subscribes to the kernel and receives events as they occur without any additional configuration.\nHowever, 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.\n- For this detection rule no additional audit rules are required.\n\n### System Integration Setup\nThe System integration allows you to collect system logs and metrics from your servers with Elastic Agent.\n\n#### The following steps should be executed in order to add the Elastic Agent System integration \"system\" to your system:\n- Go to the Kibana home page and click \u201cAdd integrations\u201d.\n- In the query bar, search for \u201cSystem\u201d and select the integration to see more details about it.\n- Click \u201cAdd System\u201d.\n- Configure the integration name and optionally add a description.\n- Review optional and advanced settings accordingly.\n- Add the newly installed \u201csystem\u201d to an existing or a new agent policy, and deploy the agent on your system from which system log files are desirable.\n- Click \u201cSave and Continue\u201d.\n- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/system).\n", + "severity": "low", + "tags": [ + "Use Case: Identity and Access Audit", + "Use Case: Threat Detection", + "Rule Type: ML", + "Rule Type: Machine Learning", + "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/" + } + ] + } + ], + "type": "machine_learning", + "version": 105 + }, + "id": "99dcf974-6587-4f65-9252-d866a3fdfd9c_105", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/9d302377-d226-4e12-b54c-1906b5aec4f6_104.json b/packages/security_detection_engine/kibana/security_rule/9d302377-d226-4e12-b54c-1906b5aec4f6_104.json new file mode 100644 index 00000000000..0beeca5cd59 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/9d302377-d226-4e12-b54c-1906b5aec4f6_104.json @@ -0,0 +1,69 @@ +{ + "attributes": { + "anomaly_threshold": 50, + "author": [ + "Elastic" + ], + "description": "Looks for anomalous access to the metadata service by an unusual process. The metadata service may be targeted in order to harvest credentials or user data scripts containing secrets.", + "false_positives": [ + "A newly installed program or one that runs very rarely as part of a monthly or quarterly workflow could trigger this detection rule." + ], + "from": "now-45m", + "interval": "15m", + "license": "Elastic License v2", + "machine_learning_job_id": [ + "v3_linux_rare_metadata_process" + ], + "name": "Unusual Linux Process Calling the Metadata Service", + "related_integrations": [ + { + "package": "auditd_manager", + "version": "^1.0.0" + }, + { + "package": "endpoint", + "version": "^8.2.0" + } + ], + "risk_score": 21, + "rule_id": "9d302377-d226-4e12-b54c-1906b5aec4f6", + "setup": "## Setup\n\nThis rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:\n- Elastic Defend\n- Auditd Manager\n\n### Anomaly Detection Setup\n\nOnce the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the \"Definition\" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).\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 to your 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/current/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\n### Auditd Manager Integration Setup\nThe Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel.\nAuditd Manager 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.\n\n#### The following steps should be executed in order to add the Elastic Agent System integration \"auditd_manager\" to your system:\n- Go to the Kibana home page and click \u201cAdd integrations\u201d.\n- In the query bar, search for \u201cAuditd Manager\u201d and select the integration to see more details about it.\n- Click \u201cAdd Auditd Manager\u201d.\n- Configure the integration name and optionally add a description.\n- Review optional and advanced settings accordingly.\n- Add the newly installed \u201cauditd manager\u201d to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable.\n- Click \u201cSave and Continue\u201d.\n- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/auditd_manager).\n\n#### Rule Specific Setup Note\nAuditd Manager subscribes to the kernel and receives events as they occur without any additional configuration.\nHowever, 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.\n- For this detection rule no additional audit rules are required.\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Rule Type: ML", + "Rule Type: Machine Learning", + "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/" + } + ] + } + ] + } + ], + "type": "machine_learning", + "version": 104 + }, + "id": "9d302377-d226-4e12-b54c-1906b5aec4f6_104", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/a61809f3-fb5b-465c-8bff-23a8a068ac60_7.json b/packages/security_detection_engine/kibana/security_rule/a61809f3-fb5b-465c-8bff-23a8a068ac60_7.json new file mode 100644 index 00000000000..ff131e30411 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/a61809f3-fb5b-465c-8bff-23a8a068ac60_7.json @@ -0,0 +1,127 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule is triggered when a Windows registry indicator from the Threat Intel Filebeat module or integrations has a match against an event that contains registry data.", + "from": "now-65m", + "index": [ + "auditbeat-*", + "endgame-*", + "filebeat-*", + "logs-*", + "winlogbeat-*" + ], + "interval": "1h", + "language": "kuery", + "license": "Elastic License v2", + "name": "Threat Intel Windows Registry Indicator Match", + "note": "## Triage and Analysis\n\n### Investigating Threat Intel Windows Registry Indicator Match\n\nThreat Intel indicator match rules allow matching from a local observation, such as an endpoint event that records a file hash with an entry of a file hash stored within the Threat Intel integrations index.\n\nMatches are based on threat intelligence data that's been ingested during the last 30 days. Some integrations don't place expiration dates on their threat indicators, so we strongly recommend validating ingested threat indicators and reviewing match results. When reviewing match results, check associated activity to determine whether the event requires additional investigation.\n\nThis rule is triggered when a Windows registry indicator from the Threat Intel Filebeat module or a threat intelligence integration matches against an event that contains registry data.\n\n> **Note**:\n> This investigation guide uses the [Osquery Markdown Plugin](https://www.elastic.co/guide/en/security/master/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- Check related threat reports to gain context about the registry indicator of compromise (IoC) and to understand if it's a system-native mechanism abused for persistence, to store data, to disable security mechanisms, etc. Use this information to define the appropriate triage and respond steps.\n- Identify the process responsible for the registry operation and 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- Retrieve the involved process executable and 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- Using the data collected through the analysis, scope users targeted and other machines infected in the environment.\n\n### False Positive Analysis\n\n- Adversaries can leverage dual-use registry mechanisms that are commonly used by normal applications. These registry keys can be added into indicator lists creating the potential for false positives.\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": "registry.path:*\n", + "references": [ + "https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-threatintel.html", + "https://www.elastic.co/guide/en/security/master/es-threat-intel-integrations.html", + "https://www.elastic.co/security/tip" + ], + "required_fields": [ + { + "ecs": true, + "name": "registry.path", + "type": "keyword" + } + ], + "risk_score": 99, + "rule_id": "a61809f3-fb5b-465c-8bff-23a8a068ac60", + "setup": "## Setup\n\nThis rule needs threat intelligence indicators to work.\nThreat intelligence indicators can be collected using an [Elastic Agent integration](https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html#agent-ti-integration),\nthe [Threat Intel module](https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html#ti-mod-integration),\nor a [custom integration](https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html#custom-ti-integration).\n\nMore information can be found [here](https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html).\n", + "severity": "critical", + "tags": [ + "OS: Windows", + "Data Source: Elastic Endgame", + "Rule Type: Threat Match" + ], + "threat_filters": [ + { + "$state": { + "store": "appState" + }, + "meta": { + "disabled": false, + "key": "event.category", + "negate": false, + "params": { + "query": "threat" + }, + "type": "phrase" + }, + "query": { + "match_phrase": { + "event.category": "threat" + } + } + }, + { + "$state": { + "store": "appState" + }, + "meta": { + "disabled": false, + "key": "event.kind", + "negate": false, + "params": { + "query": "enrichment" + }, + "type": "phrase" + }, + "query": { + "match_phrase": { + "event.kind": "enrichment" + } + } + }, + { + "$state": { + "store": "appState" + }, + "meta": { + "disabled": false, + "key": "event.type", + "negate": false, + "params": { + "query": "indicator" + }, + "type": "phrase" + }, + "query": { + "match_phrase": { + "event.type": "indicator" + } + } + } + ], + "threat_index": [ + "filebeat-*", + "logs-ti_*" + ], + "threat_indicator_path": "threat.indicator", + "threat_language": "kuery", + "threat_mapping": [ + { + "entries": [ + { + "field": "registry.path", + "type": "mapping", + "value": "threat.indicator.registry.path" + } + ] + } + ], + "threat_query": "@timestamp >= \"now-30d/d\" and event.module:(threatintel or ti_*) and threat.indicator.registry.path:* and not labels.is_ioc_transform_source:\"true\"", + "timeline_id": "495ad7a7-316e-4544-8a0f-9c098daee76e", + "timeline_title": "Generic Threat Match Timeline", + "timestamp_override": "event.ingested", + "type": "threat_match", + "version": 7 + }, + "id": "a61809f3-fb5b-465c-8bff-23a8a068ac60_7", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/aab184d3-72b3-4639-b242-6597c99d8bca_8.json b/packages/security_detection_engine/kibana/security_rule/aab184d3-72b3-4639-b242-6597c99d8bca_8.json new file mode 100644 index 00000000000..0216914a7f1 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/aab184d3-72b3-4639-b242-6597c99d8bca_8.json @@ -0,0 +1,209 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule is triggered when a hash indicator from the Threat Intel Filebeat module or integrations has a match against an event that contains file hashes, such as antivirus alerts, process creation, library load, and file operation events.", + "from": "now-65m", + "index": [ + "auditbeat-*", + "endgame-*", + "filebeat-*", + "logs-*", + "winlogbeat-*" + ], + "interval": "1h", + "language": "kuery", + "license": "Elastic License v2", + "name": "Threat Intel Hash Indicator Match", + "note": "## Triage and Analysis\n\n### Investigating Threat Intel Hash Indicator Match\n\nThreat Intel indicator match rules allow matching from a local observation, such as an endpoint event that records a file hash with an entry of a file hash stored within the Threat Intel integrations index.\n\nMatches are based on threat intelligence data that's been ingested during the last 30 days. Some integrations don't place expiration dates on their threat indicators, so we strongly recommend validating ingested threat indicators and reviewing match results. When reviewing match results, check associated activity to determine whether the event requires additional investigation.\n\nThis rule is triggered when a hash indicator from the Threat Intel Filebeat module or an indicator ingested from a threat intelligence integration matches against an event that contains file hashes, such as antivirus alerts, file operation events, etc.\n\n> **Note**:\n> This investigation guide uses the [Osquery Markdown Plugin](https://www.elastic.co/guide/en/security/master/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- Gain context about the field that matched the local observation. This information can be found in the `threat.indicator.matched.field` field.\n- Investigate the hash , which can be found in the `threat.indicator.matched.atomic` field:\n - Search for the existence and reputation of the hash in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.\n - Scope other potentially compromised hosts in your environment by mapping hosts with file operations involving the same hash.\n- Identify the process that created the file.\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 - Enrich the information that you have right now by determining how the file was dropped, where it was downloaded from, etc. This can help you determine if the event is part of an ongoing campaign against the organization.\n- Retrieve the involved file and 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- Using the data collected through the analysis, scope users targeted and other machines infected in the environment.\n\n### False Positive Analysis\n\n- Adversaries often use legitimate tools as network administrators, such as `PsExec` or `AdFind`. These tools are often included in indicator lists, which creates the potential for false positives.\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": "file.hash.*:* or process.hash.*:* or dll.hash.*:*\n", + "references": [ + "https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-threatintel.html", + "https://www.elastic.co/guide/en/security/master/es-threat-intel-integrations.html", + "https://www.elastic.co/security/tip" + ], + "required_fields": [ + { + "ecs": false, + "name": "dll.hash.*", + "type": "unknown" + }, + { + "ecs": false, + "name": "file.hash.*", + "type": "unknown" + }, + { + "ecs": false, + "name": "process.hash.*", + "type": "unknown" + } + ], + "risk_score": 99, + "rule_id": "aab184d3-72b3-4639-b242-6597c99d8bca", + "setup": "## Setup\n\nThis rule needs threat intelligence indicators to work.\nThreat intelligence indicators can be collected using an [Elastic Agent integration](https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html#agent-ti-integration),\nthe [Threat Intel module](https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html#ti-mod-integration),\nor a [custom integration](https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html#custom-ti-integration).\n\nMore information can be found [here](https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html).\n", + "severity": "critical", + "tags": [ + "OS: Windows", + "Data Source: Elastic Endgame", + "Rule Type: Threat Match" + ], + "threat_filters": [ + { + "$state": { + "store": "appState" + }, + "meta": { + "disabled": false, + "key": "event.category", + "negate": false, + "params": { + "query": "threat" + }, + "type": "phrase" + }, + "query": { + "match_phrase": { + "event.category": "threat" + } + } + }, + { + "$state": { + "store": "appState" + }, + "meta": { + "disabled": false, + "key": "event.kind", + "negate": false, + "params": { + "query": "enrichment" + }, + "type": "phrase" + }, + "query": { + "match_phrase": { + "event.kind": "enrichment" + } + } + }, + { + "$state": { + "store": "appState" + }, + "meta": { + "disabled": false, + "key": "event.type", + "negate": false, + "params": { + "query": "indicator" + }, + "type": "phrase" + }, + "query": { + "match_phrase": { + "event.type": "indicator" + } + } + } + ], + "threat_index": [ + "filebeat-*", + "logs-ti_*" + ], + "threat_indicator_path": "threat.indicator", + "threat_language": "kuery", + "threat_mapping": [ + { + "entries": [ + { + "field": "file.hash.md5", + "type": "mapping", + "value": "threat.indicator.file.hash.md5" + } + ] + }, + { + "entries": [ + { + "field": "file.hash.sha1", + "type": "mapping", + "value": "threat.indicator.file.hash.sha1" + } + ] + }, + { + "entries": [ + { + "field": "file.hash.sha256", + "type": "mapping", + "value": "threat.indicator.file.hash.sha256" + } + ] + }, + { + "entries": [ + { + "field": "dll.hash.md5", + "type": "mapping", + "value": "threat.indicator.file.hash.md5" + } + ] + }, + { + "entries": [ + { + "field": "dll.hash.sha1", + "type": "mapping", + "value": "threat.indicator.file.hash.sha1" + } + ] + }, + { + "entries": [ + { + "field": "dll.hash.sha256", + "type": "mapping", + "value": "threat.indicator.file.hash.sha256" + } + ] + }, + { + "entries": [ + { + "field": "process.hash.md5", + "type": "mapping", + "value": "threat.indicator.file.hash.md5" + } + ] + }, + { + "entries": [ + { + "field": "process.hash.sha1", + "type": "mapping", + "value": "threat.indicator.file.hash.sha1" + } + ] + }, + { + "entries": [ + { + "field": "process.hash.sha256", + "type": "mapping", + "value": "threat.indicator.file.hash.sha256" + } + ] + } + ], + "threat_query": "@timestamp >= \"now-30d/d\" and event.module:(threatintel or ti_*) and (threat.indicator.file.hash.*:* or threat.indicator.file.pe.imphash:*) and not labels.is_ioc_transform_source:\"true\"", + "timeline_id": "495ad7a7-316e-4544-8a0f-9c098daee76e", + "timeline_title": "Generic Threat Match Timeline", + "timestamp_override": "event.ingested", + "type": "threat_match", + "version": 8 + }, + "id": "aab184d3-72b3-4639-b242-6597c99d8bca_8", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/abae61a8-c560-4dbd-acca-1e1438bff36b_104.json b/packages/security_detection_engine/kibana/security_rule/abae61a8-c560-4dbd-acca-1e1438bff36b_104.json new file mode 100644 index 00000000000..edf0eb8a905 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/abae61a8-c560-4dbd-acca-1e1438bff36b_104.json @@ -0,0 +1,69 @@ +{ + "attributes": { + "anomaly_threshold": 50, + "author": [ + "Elastic" + ], + "description": "Looks for anomalous access to the metadata service by an unusual process. The metadata service may be targeted in order to harvest credentials or user data scripts containing secrets.", + "false_positives": [ + "A newly installed program or one that runs very rarely as part of a monthly or quarterly workflow could trigger this detection rule." + ], + "from": "now-45m", + "interval": "15m", + "license": "Elastic License v2", + "machine_learning_job_id": [ + "v3_windows_rare_metadata_process" + ], + "name": "Unusual Windows Process Calling the Metadata Service", + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "windows", + "version": "^1.5.0" + } + ], + "risk_score": 21, + "rule_id": "abae61a8-c560-4dbd-acca-1e1438bff36b", + "setup": "## Setup\n\nThis rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:\n- Elastic Defend\n- Windows\n\n### Anomaly Detection Setup\n\nOnce the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the \"Definition\" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).\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 to your 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/current/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\n### Windows Integration Setup\nThe Windows integration allows you to monitor the Windows OS, services, applications, and more.\n\n#### The following steps should be executed in order to add the Elastic Agent System integration \"windows\" to your system:\n- Go to the Kibana home page and click \u201cAdd integrations\u201d.\n- In the query bar, search for \u201cWindows\u201d and select the integration to see more details about it.\n- Click \u201cAdd Windows\u201d.\n- Configure the integration name and optionally add a description.\n- Review optional and advanced settings accordingly.\n- Add the newly installed \u201cwindows\u201d to an existing or a new agent policy, and deploy the agent on your system from which windows log files are desirable.\n- Click \u201cSave and Continue\u201d.\n- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/windows).\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Rule Type: ML", + "Rule Type: Machine Learning", + "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/" + } + ] + } + ] + } + ], + "type": "machine_learning", + "version": 104 + }, + "id": "abae61a8-c560-4dbd-acca-1e1438bff36b_104", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/ac706eae-d5ec-4b14-b4fd-e8ba8086f0e1_209.json b/packages/security_detection_engine/kibana/security_rule/ac706eae-d5ec-4b14-b4fd-e8ba8086f0e1_209.json new file mode 100644 index 00000000000..985732dce0c --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/ac706eae-d5ec-4b14-b4fd-e8ba8086f0e1_209.json @@ -0,0 +1,43 @@ +{ + "attributes": { + "anomaly_threshold": 75, + "author": [ + "Elastic" + ], + "description": "A machine learning job detected an AWS API command that, while not inherently suspicious or abnormal, is being made by a user context that does not normally use the command. This can be the result of compromised credentials or keys as someone uses a valid account to persist, move laterally, or exfiltrate data.", + "false_positives": [ + "New or unusual user command activity can be due to manual troubleshooting or reconfiguration; changes in cloud automation scripts or workflows; adoption of new services; or changes in the way services are used." + ], + "from": "now-2h", + "interval": "15m", + "license": "Elastic License v2", + "machine_learning_job_id": "rare_method_for_a_username", + "name": "Unusual AWS Command for a User", + "note": "## Triage and analysis\n\n### Investigating Unusual AWS Command for a User\n\nCloudTrail logging provides visibility on actions taken within an AWS environment. By monitoring these events and understanding what is considered normal behavior within an organization, you can spot suspicious or malicious activity when deviations occur.\n\nThis rule uses a machine learning job to detect an AWS API command that while not inherently suspicious or abnormal, is being made by a user context that does not normally use the command. This can be the result of compromised credentials or keys as someone uses a valid account to persist, move laterally, or exfiltrate data.\n\nDetection alerts from this rule indicate an AWS API command or method call that is rare and unusual for the calling IAM user.\n\n#### Possible investigation steps\n\n- Identify the user account involved and the action performed. Verify whether it should perform this kind of action.\n - Examine the user identity in the `aws.cloudtrail.user_identity.arn` field and the access key ID in the `aws.cloudtrail.user_identity.access_key_id` field, which can help identify the precise user context.\n - The user agent details in the `user_agent.original` field may also indicate what kind of a client made the request.\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 might indicate the source of the program or the nature of its tasks.\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- Examine the history of the command. If the command only manifested recently, it might be part of a new automation module or script. If it has a consistent cadence (for example, it appears in small numbers on a weekly or monthly cadence), it might be part of a housekeeping or maintenance process. You can find the command in the `event.action field` field.\n\n### Related Rules\n\n- Unusual City For an AWS Command - 809b70d3-e2c3-455e-af1b-2626a5a1a276\n- Unusual Country For an AWS Command - dca28dee-c999-400f-b640-50a081cc0fd1\n- Rare AWS Error Code - 19de8096-e2b0-4bd8-80c9-34a820813fff\n- Spike in AWS Error Messages - 78d3d8d9-b476-451d-a9e0-7a5addd70670\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", + "references": [ + "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html" + ], + "related_integrations": [ + { + "package": "aws", + "version": "^2.0.0" + } + ], + "risk_score": 21, + "rule_id": "ac706eae-d5ec-4b14-b4fd-e8ba8086f0e1", + "setup": "## Setup\n\nThis rule requires the installation of associated Machine Learning jobs, as well as data coming in from AWS.\n\n### Anomaly Detection Setup\n\nOnce the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the \"Definition\" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).\n\n### AWS Integration Setup\nThe AWS integration allows you to collect logs and metrics from Amazon Web Services (AWS) with Elastic Agent.\n\n#### The following steps should be executed in order to add the Elastic Agent System integration \"aws\" to your system:\n- Go to the Kibana home page and click \u201cAdd integrations\u201d.\n- In the query bar, search for \u201cAWS\u201d and select the integration to see more details about it.\n- Click \u201cAdd AWS\u201d.\n- Configure the integration name and optionally add a description.\n- Review optional and advanced settings accordingly.\n- Add the newly installed \u201caws\u201d to an existing or a new agent policy, and deploy the agent on your system from which aws log files are desirable.\n- Click \u201cSave and Continue\u201d.\n- For more details on the integration refer to the [helper guide](https://www.elastic.co/docs/current/integrations/aws).\n", + "severity": "low", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Rule Type: ML", + "Rule Type: Machine Learning", + "Resources: Investigation Guide" + ], + "type": "machine_learning", + "version": 209 + }, + "id": "ac706eae-d5ec-4b14-b4fd-e8ba8086f0e1_209", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/b240bfb8-26b7-4e5e-924e-218144a3fa71_104.json b/packages/security_detection_engine/kibana/security_rule/b240bfb8-26b7-4e5e-924e-218144a3fa71_104.json new file mode 100644 index 00000000000..02c9ab21b55 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/b240bfb8-26b7-4e5e-924e-218144a3fa71_104.json @@ -0,0 +1,43 @@ +{ + "attributes": { + "anomaly_threshold": 75, + "author": [ + "Elastic" + ], + "description": "A machine learning job detected an unusually large spike in network traffic. Such a burst of traffic, if not caused by a surge in business activity, can be due to suspicious or malicious activity. Large-scale data exfiltration may produce a burst of network traffic; this could also be due to unusually large amounts of reconnaissance or enumeration traffic. Denial-of-service attacks or traffic floods may also produce such a surge in traffic.", + "false_positives": [ + "Business workflows that occur very occasionally, and involve an unusual surge in network traffic, can trigger this alert. A new business workflow or a surge in business activity may trigger this alert. A misconfigured network application or firewall may trigger this alert." + ], + "from": "now-30m", + "interval": "15m", + "license": "Elastic License v2", + "machine_learning_job_id": "high_count_network_events", + "name": "Spike in Network Traffic", + "references": [ + "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "network_traffic", + "version": "^1.1.0" + } + ], + "risk_score": 21, + "rule_id": "b240bfb8-26b7-4e5e-924e-218144a3fa71", + "setup": "## Setup\n\nThis rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:\n- Elastic Defend\n- Network Packet Capture\n\n### Anomaly Detection Setup\n\nOnce the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the \"Definition\" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).\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 to your 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/current/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\n### Network Packet Capture Integration Setup\nThe Network Packet Capture integration sniffs network packets on a host and dissects known protocols. Monitoring the network traffic is critical to gaining observability and securing your environment \u2014 ensuring high levels of performance and security. The Network Packet Capture integration captures the network traffic between your application servers, decodes common application layer protocols and records the interesting fields for each transaction.\n\n#### The following steps should be executed in order to add the Elastic Agent System integration \"network_traffic\" to your system:\n- Go to the Kibana home page and click \u201cAdd integrations\u201d.\n- In the query bar, search for \u201cNetwork Packet Capture\u201d and select the integration to see more details about it.\n- Click \u201cAdd Network Packet Capture\u201d.\n- Configure the integration name and optionally add a description.\n- Review optional and advanced settings accordingly.\n- Add the newly installed \u201cnetwork_traffic\u201d to an existing or a new agent policy, and deploy the agent on your system from which network log files are desirable.\n- Click \u201cSave and Continue\u201d.\n- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/network_traffic).\n", + "severity": "low", + "tags": [ + "Use Case: Threat Detection", + "Rule Type: ML", + "Rule Type: Machine Learning" + ], + "type": "machine_learning", + "version": 104 + }, + "id": "b240bfb8-26b7-4e5e-924e-218144a3fa71_104", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/b347b919-665f-4aac-b9e8-68369bf2340c_104.json b/packages/security_detection_engine/kibana/security_rule/b347b919-665f-4aac-b9e8-68369bf2340c_104.json new file mode 100644 index 00000000000..68dee018fb9 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/b347b919-665f-4aac-b9e8-68369bf2340c_104.json @@ -0,0 +1,66 @@ +{ + "attributes": { + "anomaly_threshold": 50, + "author": [ + "Elastic" + ], + "description": "A machine learning job detected activity for a username that is not normally active, which can indicate unauthorized changes, activity by unauthorized users, lateral movement, or compromised credentials. In many organizations, new usernames are not often created apart from specific types of system activities, such as creating new accounts for new employees. These user accounts quickly become active and routine. Events from rarely used usernames can point to suspicious activity. Additionally, automated Linux fleets tend to see activity from rarely used usernames only when personnel log in to make authorized or unauthorized changes, or threat actors have acquired credentials and log in for malicious purposes. Unusual usernames can also indicate pivoting, where compromised credentials are used to try and move laterally from one host to another.", + "false_positives": [ + "Uncommon user activity can be due to an engineer logging onto a server instance in order to perform manual troubleshooting or reconfiguration." + ], + "from": "now-45m", + "interval": "15m", + "license": "Elastic License v2", + "machine_learning_job_id": [ + "v3_linux_anomalous_user_name" + ], + "name": "Unusual Linux Username", + "note": "## Triage and analysis\n\n### Investigating an Unusual Linux User\nDetection alerts from this rule indicate activity for a Linux user name that is rare and unusual. Here are some possible avenues of investigation:\n- Consider the user as identified by the username field. Is this program part of an expected workflow for the user who ran this program on this host? Could this be related to troubleshooting or debugging activity by a developer or site reliability engineer?\n- Examine the history of user activity. If this user only manifested recently, it might be a service account for a new software package. If it has a consistent cadence (for example if it runs monthly or quarterly), it might be part of a monthly or quarterly business process.\n- Examine the process arguments, title and working directory. These may provide indications as to the source of the program or the nature of the tasks that the user is performing.", + "references": [ + "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html" + ], + "related_integrations": [ + { + "package": "auditd_manager", + "version": "^1.0.0" + }, + { + "package": "endpoint", + "version": "^8.2.0" + } + ], + "risk_score": 21, + "rule_id": "b347b919-665f-4aac-b9e8-68369bf2340c", + "setup": "## Setup\n\nThis rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:\n- Elastic Defend\n- Auditd Manager\n\n### Anomaly Detection Setup\n\nOnce the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the \"Definition\" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).\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 to your 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/current/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\n### Auditd Manager Integration Setup\nThe Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel.\nAuditd Manager 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.\n\n#### The following steps should be executed in order to add the Elastic Agent System integration \"auditd_manager\" to your system:\n- Go to the Kibana home page and click \u201cAdd integrations\u201d.\n- In the query bar, search for \u201cAuditd Manager\u201d and select the integration to see more details about it.\n- Click \u201cAdd Auditd Manager\u201d.\n- Configure the integration name and optionally add a description.\n- Review optional and advanced settings accordingly.\n- Add the newly installed \u201cauditd manager\u201d to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable.\n- Click \u201cSave and Continue\u201d.\n- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/auditd_manager).\n\n#### Rule Specific Setup Note\nAuditd Manager subscribes to the kernel and receives events as they occur without any additional configuration.\nHowever, 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.\n- For this detection rule no additional audit rules are required.\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Rule Type: ML", + "Rule Type: Machine Learning", + "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/" + } + ] + } + ], + "type": "machine_learning", + "version": 104 + }, + "id": "b347b919-665f-4aac-b9e8-68369bf2340c_104", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/b66b7e2b-d50a-49b9-a6fc-3a383baedc6b_1.json b/packages/security_detection_engine/kibana/security_rule/b66b7e2b-d50a-49b9-a6fc-3a383baedc6b_1.json new file mode 100644 index 00000000000..c54ef8d8d94 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/b66b7e2b-d50a-49b9-a6fc-3a383baedc6b_1.json @@ -0,0 +1,142 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies registry modifications to default services that could enable privilege escalation to SYSTEM. Attackers with privileges from groups like Server Operators may change the ImagePath of services to executables under their control or to execute commands.", + "from": "now-9m", + "index": [ + "logs-endpoint.events.registry-*", + "logs-windows.sysmon_operational-*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "Potential Privilege Escalation via Service ImagePath Modification", + "query": "registry where host.os.type == \"windows\" and event.type == \"change\" and process.executable != null and \n event.action == \"modification\" and registry.value == \"ImagePath\" and\n registry.key : (\n \"*\\\\ADWS\", \"*\\\\AppHostSvc\", \"*\\\\AppReadiness\", \"*\\\\AudioEndpointBuilder\", \"*\\\\AxInstSV\", \"*\\\\camsvc\", \"*\\\\CertSvc\",\n \"*\\\\COMSysApp\", \"*\\\\CscService\", \"*\\\\defragsvc\", \"*\\\\DeviceAssociationService\", \"*\\\\DeviceInstall\", \"*\\\\DevQueryBroker\",\n \"*\\\\Dfs\", \"*\\\\DFSR\", \"*\\\\diagnosticshub.standardcollector.service\", \"*\\\\DiagTrack\", \"*\\\\DmEnrollmentSvc\", \"*\\\\DNS\",\n \"*\\\\dot3svc\", \"*\\\\Eaphost\", \"*\\\\GraphicsPerfSvc\", \"*\\\\hidserv\", \"*\\\\HvHost\", \"*\\\\IISADMIN\", \"*\\\\IKEEXT\",\n \"*\\\\InstallService\", \"*\\\\iphlpsvc\", \"*\\\\IsmServ\", \"*\\\\LanmanServer\", \"*\\\\MSiSCSI\", \"*\\\\NcbService\", \"*\\\\Netlogon\",\n \"*\\\\Netman\", \"*\\\\NtFrs\", \"*\\\\PlugPlay\", \"*\\\\Power\", \"*\\\\PrintNotify\", \"*\\\\ProfSvc\", \"*\\\\PushToInstall\", \"*\\\\RSoPProv\",\n \"*\\\\sacsvr\", \"*\\\\SENS\", \"*\\\\SensorDataService\", \"*\\\\SgrmBroker\", \"*\\\\ShellHWDetection\", \"*\\\\shpamsvc\", \"*\\\\StorSvc\",\n \"*\\\\svsvc\", \"*\\\\swprv\", \"*\\\\SysMain\", \"*\\\\Themes\", \"*\\\\TieringEngineService\", \"*\\\\TokenBroker\", \"*\\\\TrkWks\",\n \"*\\\\UALSVC\", \"*\\\\UserManager\", \"*\\\\vm3dservice\", \"*\\\\vmicguestinterface\", \"*\\\\vmicheartbeat\", \"*\\\\vmickvpexchange\",\n \"*\\\\vmicrdv\", \"*\\\\vmicshutdown\", \"*\\\\vmicvmsession\", \"*\\\\vmicvss\", \"*\\\\vmvss\", \"*\\\\VSS\", \"*\\\\w3logsvc\", \"*\\\\W3SVC\",\n \"*\\\\WalletService\", \"*\\\\WAS\", \"*\\\\wercplsupport\", \"*\\\\WerSvc\", \"*\\\\Winmgmt\", \"*\\\\wisvc\", \"*\\\\wmiApSrv\",\n \"*\\\\WPDBusEnum\", \"*\\\\WSearch\"\n ) and\n not (\n registry.data.strings : (\n \"?:\\\\Windows\\\\system32\\\\*.exe\",\n \"%systemroot%\\\\system32\\\\*.exe\",\n \"%windir%\\\\system32\\\\*.exe\",\n \"%SystemRoot%\\\\system32\\\\svchost.exe -k *\",\n \"%windir%\\\\system32\\\\svchost.exe -k *\"\n ) and\n not registry.data.strings : (\n \"*\\\\cmd.exe\",\n \"*\\\\cscript.exe\",\n \"*\\\\ieexec.exe\",\n \"*\\\\iexpress.exe\",\n \"*\\\\installutil.exe\",\n \"*\\\\Microsoft.Workflow.Compiler.exe\",\n \"*\\\\msbuild.exe\",\n \"*\\\\mshta.exe\",\n \"*\\\\msiexec.exe\",\n \"*\\\\msxsl.exe\",\n \"*\\\\net.exe\",\n \"*\\\\powershell.exe\",\n \"*\\\\pwsh.exe\",\n \"*\\\\reg.exe\",\n \"*\\\\RegAsm.exe\",\n \"*\\\\RegSvcs.exe\",\n \"*\\\\regsvr32.exe\",\n \"*\\\\rundll32.exe\",\n \"*\\\\vssadmin.exe\",\n \"*\\\\wbadmin.exe\",\n \"*\\\\wmic.exe\",\n \"*\\\\wscript.exe\"\n )\n )\n", + "references": [ + "https://cube0x0.github.io/Pocing-Beyond-DA/" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "windows", + "version": "^1.5.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.executable", + "type": "keyword" + }, + { + "ecs": true, + "name": "registry.data.strings", + "type": "wildcard" + }, + { + "ecs": true, + "name": "registry.key", + "type": "keyword" + }, + { + "ecs": true, + "name": "registry.value", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "b66b7e2b-d50a-49b9-a6fc-3a383baedc6b", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Execution", + "Tactic: Privilege Escalation", + "Data Source: Elastic Defend", + "Data Source: Sysmon" + ], + "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/" + } + ] + }, + { + "id": "T1574", + "name": "Hijack Execution Flow", + "reference": "https://attack.mitre.org/techniques/T1574/", + "subtechnique": [ + { + "id": "T1574.011", + "name": "Services Registry Permissions Weakness", + "reference": "https://attack.mitre.org/techniques/T1574/011/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0002", + "name": "Execution", + "reference": "https://attack.mitre.org/tactics/TA0002/" + }, + "technique": [ + { + "id": "T1569", + "name": "System Services", + "reference": "https://attack.mitre.org/techniques/T1569/", + "subtechnique": [ + { + "id": "T1569.002", + "name": "Service Execution", + "reference": "https://attack.mitre.org/techniques/T1569/002/" + } + ] + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 1 + }, + "id": "b66b7e2b-d50a-49b9-a6fc-3a383baedc6b_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/ba342eb2-583c-439f-b04d-1fdd7c1417cc_104.json b/packages/security_detection_engine/kibana/security_rule/ba342eb2-583c-439f-b04d-1fdd7c1417cc_104.json new file mode 100644 index 00000000000..71659a6c434 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/ba342eb2-583c-439f-b04d-1fdd7c1417cc_104.json @@ -0,0 +1,48 @@ +{ + "attributes": { + "anomaly_threshold": 50, + "author": [ + "Elastic" + ], + "description": "Identifies Windows processes that do not usually use the network but have unexpected network activity, which can indicate command-and-control, lateral movement, persistence, or data exfiltration activity. A process with unusual network activity can denote process exploitation or injection, where the process is used to run persistence mechanisms that allow a malicious actor remote access or control of the host, data exfiltration, and execution of unauthorized network applications.", + "false_positives": [ + "A newly installed program or one that rarely uses the network could trigger this alert." + ], + "from": "now-45m", + "interval": "15m", + "license": "Elastic License v2", + "machine_learning_job_id": [ + "v3_windows_anomalous_network_activity" + ], + "name": "Unusual Windows Network Activity", + "note": "## Triage and analysis\n\n### Investigating Unusual Network Activity\nDetection alerts from this rule indicate the presence of network activity from a Windows process for which network activity is very unusual. Here are some possible avenues of investigation:\n- Consider the IP addresses, protocol and ports. Are these used by normal but infrequent network workflows? Are they expected or unexpected?\n- If the destination IP address is remote or external, does it associate with an expected domain, organization or geography? Note: avoid interacting directly with suspected malicious IP addresses.\n- Consider the user as identified by the username field. Is this network activity part of an expected workflow for the user who ran the program?\n- Examine the history of execution. If this process only manifested recently, it might be part of a new software package. If it has a consistent cadence (for example if it runs monthly or quarterly), it might be part of a monthly or quarterly business process.\n- Examine the process arguments, title and working directory. These may provide indications as to the source of the program or the nature of the tasks it is performing.\n- Consider the same for the parent process. If the parent process is a legitimate system utility or service, this could be related to software updates or system management. If the parent process is something user-facing like an Office application, this process could be more suspicious.\n- If you have file hash values in the event data, and you suspect malware, you can optionally run a search for the file hash to see if the file is identified as malware by anti-malware tools.", + "references": [ + "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "windows", + "version": "^1.5.0" + } + ], + "risk_score": 21, + "rule_id": "ba342eb2-583c-439f-b04d-1fdd7c1417cc", + "setup": "## Setup\n\nThis rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:\n- Elastic Defend\n- Windows\n\n### Anomaly Detection Setup\n\nOnce the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the \"Definition\" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).\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 to your 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/current/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\n### Windows Integration Setup\nThe Windows integration allows you to monitor the Windows OS, services, applications, and more.\n\n#### The following steps should be executed in order to add the Elastic Agent System integration \"windows\" to your system:\n- Go to the Kibana home page and click \u201cAdd integrations\u201d.\n- In the query bar, search for \u201cWindows\u201d and select the integration to see more details about it.\n- Click \u201cAdd Windows\u201d.\n- Configure the integration name and optionally add a description.\n- Review optional and advanced settings accordingly.\n- Add the newly installed \u201cwindows\u201d to an existing or a new agent policy, and deploy the agent on your system from which windows log files are desirable.\n- Click \u201cSave and Continue\u201d.\n- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/windows).\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Rule Type: ML", + "Rule Type: Machine Learning" + ], + "type": "machine_learning", + "version": 104 + }, + "id": "ba342eb2-583c-439f-b04d-1fdd7c1417cc_104", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/c28c4d8c-f014-40ef-88b6-79a1d67cd499_104.json b/packages/security_detection_engine/kibana/security_rule/c28c4d8c-f014-40ef-88b6-79a1d67cd499_104.json new file mode 100644 index 00000000000..c3401e1194c --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/c28c4d8c-f014-40ef-88b6-79a1d67cd499_104.json @@ -0,0 +1,62 @@ +{ + "attributes": { + "anomaly_threshold": 25, + "author": [ + "Elastic" + ], + "description": "Looks for commands related to system network connection discovery from an unusual user context. This can be due to uncommon troubleshooting activity or due to a compromised account. A compromised account may be used by a threat actor to engage in system network connection discovery in order to increase their understanding of connected services and systems. This information may be used to shape follow-up behaviors such as lateral movement or additional discovery.", + "false_positives": [ + "Uncommon user command activity can be due to an engineer logging onto a server instance in order to perform manual troubleshooting or reconfiguration." + ], + "from": "now-45m", + "interval": "15m", + "license": "Elastic License v2", + "machine_learning_job_id": [ + "v3_linux_network_connection_discovery" + ], + "name": "Unusual Linux Network Connection Discovery", + "related_integrations": [ + { + "package": "auditd_manager", + "version": "^1.0.0" + }, + { + "package": "endpoint", + "version": "^8.2.0" + } + ], + "risk_score": 21, + "rule_id": "c28c4d8c-f014-40ef-88b6-79a1d67cd499", + "setup": "## Setup\n\nThis rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:\n- Elastic Defend\n- Auditd Manager\n\n### Anomaly Detection Setup\n\nOnce the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the \"Definition\" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).\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 to your 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/current/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\n### Auditd Manager Integration Setup\nThe Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel.\nAuditd Manager 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.\n\n#### The following steps should be executed in order to add the Elastic Agent System integration \"auditd_manager\" to your system:\n- Go to the Kibana home page and click \u201cAdd integrations\u201d.\n- In the query bar, search for \u201cAuditd Manager\u201d and select the integration to see more details about it.\n- Click \u201cAdd Auditd Manager\u201d.\n- Configure the integration name and optionally add a description.\n- Review optional and advanced settings accordingly.\n- Add the newly installed \u201cauditd manager\u201d to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable.\n- Click \u201cSave and Continue\u201d.\n- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/auditd_manager).\n\n#### Rule Specific Setup Note\nAuditd Manager subscribes to the kernel and receives events as they occur without any additional configuration.\nHowever, 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.\n- For this detection rule no additional audit rules are required.\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Rule Type: ML", + "Rule Type: Machine Learning", + "Tactic: Discovery" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0007", + "name": "Discovery", + "reference": "https://attack.mitre.org/tactics/TA0007/" + }, + "technique": [ + { + "id": "T1049", + "name": "System Network Connections Discovery", + "reference": "https://attack.mitre.org/techniques/T1049/" + } + ] + } + ], + "type": "machine_learning", + "version": 104 + }, + "id": "c28c4d8c-f014-40ef-88b6-79a1d67cd499_104", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/c7db5533-ca2a-41f6-a8b0-ee98abe0f573_105.json b/packages/security_detection_engine/kibana/security_rule/c7db5533-ca2a-41f6-a8b0-ee98abe0f573_105.json new file mode 100644 index 00000000000..5253d3f20a0 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/c7db5533-ca2a-41f6-a8b0-ee98abe0f573_105.json @@ -0,0 +1,44 @@ +{ + "attributes": { + "anomaly_threshold": 75, + "author": [ + "Elastic" + ], + "description": "A machine learning job detected an unusually large spike in network activity to one destination country in the network logs. This could be due to unusually large amounts of reconnaissance or enumeration traffic. Data exfiltration activity may also produce such a surge in traffic to a destination country that does not normally appear in network traffic or business workflows. Malware instances and persistence mechanisms may communicate with command-and-control (C2) infrastructure in their country of origin, which may be an unusual destination country for the source network.", + "false_positives": [ + "Business workflows that occur very occasionally, and involve an unusual surge in network traffic to one destination country, can trigger this alert. A new business workflow or a surge in business activity in a particular country may trigger this alert. Business travelers who roam to many countries for brief periods may trigger this alert if they engage in volumetric network activity." + ], + "from": "now-30m", + "interval": "15m", + "license": "Elastic License v2", + "machine_learning_job_id": "high_count_by_destination_country", + "name": "Spike in Network Traffic To a Country", + "note": "## Triage and analysis\n\n### Investigating Spike in Network Traffic To a Country\n\nMonitoring network traffic for anomalies is a good methodology for uncovering various potentially suspicious activities. For example, data exfiltration or infected machines may communicate with a command-and-control (C2) server in another country your company doesn't have business with.\n\nThis rule uses a machine learning job to detect a significant spike in the network traffic to a country, which can indicate reconnaissance or enumeration activities, an infected machine being used as a bot in a DDoS attack, or potentially data exfiltration.\n\n#### Possible investigation steps\n\n- Identify the specifics of the involved assets, such as role, criticality, and associated users.\n- Investigate other alerts associated with the involved assets during the past 48 hours.\n- Examine the data available and determine the exact users and processes involved in those connections.\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- Consider the time of day. If the user is a human (not a program or script), did the activity occurs during working hours?\n- If this activity is suspicious, contact the account owner and confirm whether they are aware of it.\n\n### False positive analysis\n\n- Understand the context of the connections by contacting the asset owners. If this activity is related to a new business process or newly implemented (approved) technology, consider adding exceptions \u2014 preferably with a combination of user and source conditions.\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- Consider implementing temporary network border rules to block or alert connections to the target country, if relevant.\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", + "references": [ + "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "network_traffic", + "version": "^1.1.0" + } + ], + "risk_score": 21, + "rule_id": "c7db5533-ca2a-41f6-a8b0-ee98abe0f573", + "setup": "## Setup\n\nThis rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:\n- Elastic Defend\n- Network Packet Capture\n\n### Anomaly Detection Setup\n\nOnce the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the \"Definition\" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).\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 to your 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/current/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\n### Network Packet Capture Integration Setup\nThe Network Packet Capture integration sniffs network packets on a host and dissects known protocols. Monitoring the network traffic is critical to gaining observability and securing your environment \u2014 ensuring high levels of performance and security. The Network Packet Capture integration captures the network traffic between your application servers, decodes common application layer protocols and records the interesting fields for each transaction.\n\n#### The following steps should be executed in order to add the Elastic Agent System integration \"network_traffic\" to your system:\n- Go to the Kibana home page and click \u201cAdd integrations\u201d.\n- In the query bar, search for \u201cNetwork Packet Capture\u201d and select the integration to see more details about it.\n- Click \u201cAdd Network Packet Capture\u201d.\n- Configure the integration name and optionally add a description.\n- Review optional and advanced settings accordingly.\n- Add the newly installed \u201cnetwork_traffic\u201d to an existing or a new agent policy, and deploy the agent on your system from which network log files are desirable.\n- Click \u201cSave and Continue\u201d.\n- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/network_traffic).\n", + "severity": "low", + "tags": [ + "Use Case: Threat Detection", + "Rule Type: ML", + "Rule Type: Machine Learning" + ], + "type": "machine_learning", + "version": 105 + }, + "id": "c7db5533-ca2a-41f6-a8b0-ee98abe0f573_105", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/cd66a419-9b3f-4f57-8ff8-ac4cd2d5f530_104.json b/packages/security_detection_engine/kibana/security_rule/cd66a419-9b3f-4f57-8ff8-ac4cd2d5f530_104.json new file mode 100644 index 00000000000..ed17e1f66c7 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/cd66a419-9b3f-4f57-8ff8-ac4cd2d5f530_104.json @@ -0,0 +1,69 @@ +{ + "attributes": { + "anomaly_threshold": 50, + "author": [ + "Elastic" + ], + "description": "Looks for compiler activity by a user context which does not normally run compilers. This can be the result of ad-hoc software changes or unauthorized software deployment. This can also be due to local privilege elevation via locally run exploits or malware activity.", + "false_positives": [ + "Uncommon compiler activity can be due to an engineer running a local build on a production or staging instance in the course of troubleshooting or fixing a software issue." + ], + "from": "now-45m", + "interval": "15m", + "license": "Elastic License v2", + "machine_learning_job_id": [ + "v3_linux_rare_user_compiler" + ], + "name": "Anomalous Linux Compiler Activity", + "related_integrations": [ + { + "package": "auditd_manager", + "version": "^1.0.0" + }, + { + "package": "endpoint", + "version": "^8.2.0" + } + ], + "risk_score": 21, + "rule_id": "cd66a419-9b3f-4f57-8ff8-ac4cd2d5f530", + "setup": "## Setup\n\nThis rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:\n- Elastic Defend\n- Auditd Manager\n\n### Anomaly Detection Setup\n\nOnce the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the \"Definition\" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).\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 to your 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/current/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\n### Auditd Manager Integration Setup\nThe Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel.\nAuditd Manager 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.\n\n#### The following steps should be executed in order to add the Elastic Agent System integration \"auditd_manager\" to your system:\n- Go to the Kibana home page and click \u201cAdd integrations\u201d.\n- In the query bar, search for \u201cAuditd Manager\u201d and select the integration to see more details about it.\n- Click \u201cAdd Auditd Manager\u201d.\n- Configure the integration name and optionally add a description.\n- Review optional and advanced settings accordingly.\n- Add the newly installed \u201cauditd manager\u201d to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable.\n- Click \u201cSave and Continue\u201d.\n- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/auditd_manager).\n\n#### Rule Specific Setup Note\nAuditd Manager subscribes to the kernel and receives events as they occur without any additional configuration.\nHowever, 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.\n- For this detection rule no additional audit rules are required.\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Rule Type: ML", + "Rule Type: Machine Learning", + "Tactic: Resource Development" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0042", + "name": "Resource Development", + "reference": "https://attack.mitre.org/tactics/TA0042/" + }, + "technique": [ + { + "id": "T1588", + "name": "Obtain Capabilities", + "reference": "https://attack.mitre.org/techniques/T1588/", + "subtechnique": [ + { + "id": "T1588.001", + "name": "Malware", + "reference": "https://attack.mitre.org/techniques/T1588/001/" + } + ] + } + ] + } + ], + "type": "machine_learning", + "version": 104 + }, + "id": "cd66a419-9b3f-4f57-8ff8-ac4cd2d5f530_104", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/d4af3a06-1e0a-48ec-b96a-faf2309fae46_104.json b/packages/security_detection_engine/kibana/security_rule/d4af3a06-1e0a-48ec-b96a-faf2309fae46_104.json new file mode 100644 index 00000000000..61173a0a14e --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/d4af3a06-1e0a-48ec-b96a-faf2309fae46_104.json @@ -0,0 +1,62 @@ +{ + "attributes": { + "anomaly_threshold": 75, + "author": [ + "Elastic" + ], + "description": "Looks for commands related to system information discovery from an unusual user context. This can be due to uncommon troubleshooting activity or due to a compromised account. A compromised account may be used to engage in system information discovery in order to gather detailed information about system configuration and software versions. This may be a precursor to selection of a persistence mechanism or a method of privilege elevation.", + "false_positives": [ + "Uncommon user command activity can be due to an engineer logging onto a server instance in order to perform manual troubleshooting or reconfiguration." + ], + "from": "now-45m", + "interval": "15m", + "license": "Elastic License v2", + "machine_learning_job_id": [ + "v3_linux_system_information_discovery" + ], + "name": "Unusual Linux System Information Discovery Activity", + "related_integrations": [ + { + "package": "auditd_manager", + "version": "^1.0.0" + }, + { + "package": "endpoint", + "version": "^8.2.0" + } + ], + "risk_score": 21, + "rule_id": "d4af3a06-1e0a-48ec-b96a-faf2309fae46", + "setup": "## Setup\n\nThis rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:\n- Elastic Defend\n- Auditd Manager\n\n### Anomaly Detection Setup\n\nOnce the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the \"Definition\" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).\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 to your 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/current/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\n### Auditd Manager Integration Setup\nThe Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel.\nAuditd Manager 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.\n\n#### The following steps should be executed in order to add the Elastic Agent System integration \"auditd_manager\" to your system:\n- Go to the Kibana home page and click \u201cAdd integrations\u201d.\n- In the query bar, search for \u201cAuditd Manager\u201d and select the integration to see more details about it.\n- Click \u201cAdd Auditd Manager\u201d.\n- Configure the integration name and optionally add a description.\n- Review optional and advanced settings accordingly.\n- Add the newly installed \u201cauditd manager\u201d to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable.\n- Click \u201cSave and Continue\u201d.\n- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/auditd_manager).\n\n#### Rule Specific Setup Note\nAuditd Manager subscribes to the kernel and receives events as they occur without any additional configuration.\nHowever, 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.\n- For this detection rule no additional audit rules are required.\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Rule Type: ML", + "Rule Type: Machine Learning", + "Tactic: Discovery" + ], + "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/" + } + ] + } + ], + "type": "machine_learning", + "version": 104 + }, + "id": "d4af3a06-1e0a-48ec-b96a-faf2309fae46_104", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/d4b73fa0-9d43-465e-b8bf-50230da6718b_104.json b/packages/security_detection_engine/kibana/security_rule/d4b73fa0-9d43-465e-b8bf-50230da6718b_104.json new file mode 100644 index 00000000000..b195068b708 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/d4b73fa0-9d43-465e-b8bf-50230da6718b_104.json @@ -0,0 +1,66 @@ +{ + "attributes": { + "anomaly_threshold": 75, + "author": [ + "Elastic" + ], + "description": "A machine learning job detected a user logging in from an IP address that is unusual for the user. This can be due to credentialed access via a compromised account when the user and the threat actor are in different locations. An unusual source IP address for a username could also be due to lateral movement when a compromised account is used to pivot between hosts.", + "false_positives": [ + "Business travelers who roam to new locations may trigger this alert." + ], + "from": "now-30m", + "interval": "15m", + "license": "Elastic License v2", + "machine_learning_job_id": "auth_rare_source_ip_for_a_user", + "name": "Unusual Source IP for a User to Logon from", + "references": [ + "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html" + ], + "related_integrations": [ + { + "package": "auditd_manager", + "version": "^1.0.0" + }, + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "system", + "version": "^1.6.4" + } + ], + "risk_score": 21, + "rule_id": "d4b73fa0-9d43-465e-b8bf-50230da6718b", + "setup": "## Setup\n\nThis rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:\n- Elastic Defend\n- Auditd Manager\n- System\n\n### Anomaly Detection Setup\n\nOnce the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the \"Definition\" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).\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 to your 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/current/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\n### Auditd Manager Integration Setup\nThe Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel.\nAuditd Manager 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.\n\n#### The following steps should be executed in order to add the Elastic Agent System integration \"auditd_manager\" to your system:\n- Go to the Kibana home page and click \u201cAdd integrations\u201d.\n- In the query bar, search for \u201cAuditd Manager\u201d and select the integration to see more details about it.\n- Click \u201cAdd Auditd Manager\u201d.\n- Configure the integration name and optionally add a description.\n- Review optional and advanced settings accordingly.\n- Add the newly installed \u201cauditd manager\u201d to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable.\n- Click \u201cSave and Continue\u201d.\n- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/auditd_manager).\n\n#### Rule Specific Setup Note\nAuditd Manager subscribes to the kernel and receives events as they occur without any additional configuration.\nHowever, 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.\n- For this detection rule no additional audit rules are required.\n\n### System Integration Setup\nThe System integration allows you to collect system logs and metrics from your servers with Elastic Agent.\n\n#### The following steps should be executed in order to add the Elastic Agent System integration \"system\" to your system:\n- Go to the Kibana home page and click \u201cAdd integrations\u201d.\n- In the query bar, search for \u201cSystem\u201d and select the integration to see more details about it.\n- Click \u201cAdd System\u201d.\n- Configure the integration name and optionally add a description.\n- Review optional and advanced settings accordingly.\n- Add the newly installed \u201csystem\u201d to an existing or a new agent policy, and deploy the agent on your system from which system log files are desirable.\n- Click \u201cSave and Continue\u201d.\n- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/system).\n", + "severity": "low", + "tags": [ + "Use Case: Identity and Access Audit", + "Use Case: Threat Detection", + "Rule Type: ML", + "Rule Type: Machine Learning", + "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/" + } + ] + } + ], + "type": "machine_learning", + "version": 104 + }, + "id": "d4b73fa0-9d43-465e-b8bf-50230da6718b_104", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/d7d5c059-c19a-4a96-8ae3-41496ef3bcf9_104.json b/packages/security_detection_engine/kibana/security_rule/d7d5c059-c19a-4a96-8ae3-41496ef3bcf9_104.json new file mode 100644 index 00000000000..406638d6aa0 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/d7d5c059-c19a-4a96-8ae3-41496ef3bcf9_104.json @@ -0,0 +1,66 @@ +{ + "attributes": { + "anomaly_threshold": 75, + "author": [ + "Elastic" + ], + "description": "A machine learning job found an unusually large spike in successful authentication events. This can be due to password spraying, user enumeration or brute force activity.", + "false_positives": [ + "Build servers and CI systems can sometimes trigger this alert. Security test cycles that include brute force or password spraying activities may trigger this alert." + ], + "from": "now-30m", + "interval": "15m", + "license": "Elastic License v2", + "machine_learning_job_id": "auth_high_count_logon_events", + "name": "Spike in Logon Events", + "references": [ + "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html" + ], + "related_integrations": [ + { + "package": "auditd_manager", + "version": "^1.0.0" + }, + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "system", + "version": "^1.6.4" + } + ], + "risk_score": 21, + "rule_id": "d7d5c059-c19a-4a96-8ae3-41496ef3bcf9", + "setup": "## Setup\n\nThis rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:\n- Elastic Defend\n- Auditd Manager\n- System\n\n### Anomaly Detection Setup\n\nOnce the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the \"Definition\" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).\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 to your 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/current/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\n### Auditd Manager Integration Setup\nThe Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel.\nAuditd Manager 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.\n\n#### The following steps should be executed in order to add the Elastic Agent System integration \"auditd_manager\" to your system:\n- Go to the Kibana home page and click \u201cAdd integrations\u201d.\n- In the query bar, search for \u201cAuditd Manager\u201d and select the integration to see more details about it.\n- Click \u201cAdd Auditd Manager\u201d.\n- Configure the integration name and optionally add a description.\n- Review optional and advanced settings accordingly.\n- Add the newly installed \u201cauditd manager\u201d to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable.\n- Click \u201cSave and Continue\u201d.\n- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/auditd_manager).\n\n#### Rule Specific Setup Note\nAuditd Manager subscribes to the kernel and receives events as they occur without any additional configuration.\nHowever, 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.\n- For this detection rule no additional audit rules are required.\n\n### System Integration Setup\nThe System integration allows you to collect system logs and metrics from your servers with Elastic Agent.\n\n#### The following steps should be executed in order to add the Elastic Agent System integration \"system\" to your system:\n- Go to the Kibana home page and click \u201cAdd integrations\u201d.\n- In the query bar, search for \u201cSystem\u201d and select the integration to see more details about it.\n- Click \u201cAdd System\u201d.\n- Configure the integration name and optionally add a description.\n- Review optional and advanced settings accordingly.\n- Add the newly installed \u201csystem\u201d to an existing or a new agent policy, and deploy the agent on your system from which system log files are desirable.\n- Click \u201cSave and Continue\u201d.\n- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/system).\n", + "severity": "low", + "tags": [ + "Use Case: Identity and Access Audit", + "Use Case: Threat Detection", + "Rule Type: ML", + "Rule Type: Machine Learning", + "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/" + } + ] + } + ], + "type": "machine_learning", + "version": 104 + }, + "id": "d7d5c059-c19a-4a96-8ae3-41496ef3bcf9_104", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/d93e61db-82d6-4095-99aa-714988118064_1.json b/packages/security_detection_engine/kibana/security_rule/d93e61db-82d6-4095-99aa-714988118064_1.json new file mode 100644 index 00000000000..c89dc959d0b --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/d93e61db-82d6-4095-99aa-714988118064_1.json @@ -0,0 +1,129 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "Identifies the execution of wbadmin to access the NTDS.dit file in a domain controller. Attackers with privileges from groups like Backup Operators can abuse the utility to perform credential access and compromise the domain.", + "from": "now-9m", + "index": [ + "winlogbeat-*", + "logs-endpoint.events.process-*", + "logs-windows.*", + "endgame-*", + "logs-system.security*" + ], + "language": "eql", + "license": "Elastic License v2", + "name": "NTDS Dump via Wbadmin", + "query": "process where host.os.type == \"windows\" and event.type == \"start\" and\n (process.name : \"wbadmin.exe\" or ?process.pe.original_file_name : \"wbadmin.exe\") and \n process.args : \"recovery\" and process.command_line : \"*ntds.dit*\"\n", + "references": [ + "https://medium.com/r3d-buck3t/windows-privesc-with-sebackupprivilege-65d2cd1eb960" + ], + "related_integrations": [ + { + "package": "windows", + "version": "^1.5.0" + }, + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "system", + "version": "^1.6.4" + } + ], + "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.pe.original_file_name", + "type": "keyword" + } + ], + "risk_score": 47, + "rule_id": "d93e61db-82d6-4095-99aa-714988118064", + "severity": "medium", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Tactic: Credential Access", + "Data Source: Elastic Endgame", + "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/" + }, + { + "id": "T1003.003", + "name": "NTDS", + "reference": "https://attack.mitre.org/techniques/T1003/003/" + } + ] + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1006", + "name": "Direct Volume Access", + "reference": "https://attack.mitre.org/techniques/T1006/" + } + ] + } + ], + "timestamp_override": "event.ingested", + "type": "eql", + "version": 1 + }, + "id": "d93e61db-82d6-4095-99aa-714988118064_1", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/dca28dee-c999-400f-b640-50a081cc0fd1_209.json b/packages/security_detection_engine/kibana/security_rule/dca28dee-c999-400f-b640-50a081cc0fd1_209.json new file mode 100644 index 00000000000..d2adedba36f --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/dca28dee-c999-400f-b640-50a081cc0fd1_209.json @@ -0,0 +1,43 @@ +{ + "attributes": { + "anomaly_threshold": 50, + "author": [ + "Elastic" + ], + "description": "A machine learning job detected AWS command activity that, while not inherently suspicious or abnormal, is sourcing from a geolocation (country) that is unusual for the command. This can be the result of compromised credentials or keys being used by a threat actor in a different geography than the authorized user(s).", + "false_positives": [ + "New or unusual command and user geolocation activity can be due to manual troubleshooting or reconfiguration; changes in cloud automation scripts or workflows; adoption of new services; expansion into new regions; increased adoption of work from home policies; or users who travel frequently." + ], + "from": "now-2h", + "interval": "15m", + "license": "Elastic License v2", + "machine_learning_job_id": "rare_method_for_a_country", + "name": "Unusual Country For an AWS Command", + "note": "## Triage and analysis\n\n### Investigating Unusual Country For an AWS Command\n\nCloudTrail logging provides visibility on actions taken within an AWS environment. By monitoring these events and understanding what is considered normal behavior within an organization, you can spot suspicious or malicious activity when deviations occur.\n\nThis rule uses a machine learning job to detect an AWS API command that while not inherently suspicious or abnormal, is sourcing from a geolocation (country) that is unusual for the command. This can be the result of compromised credentials or keys used by a threat actor in a different geography than the authorized user(s).\n\nDetection alerts from this rule indicate an AWS API command or method call that is rare and unusual for the geolocation of the source IP address.\n\n#### Possible investigation steps\n\n- Identify the user account involved and the action performed. Verify whether it should perform this kind of action.\n - Examine the user identity in the `aws.cloudtrail.user_identity.arn` field and the access key ID in the `aws.cloudtrail.user_identity.access_key_id` field, which can help identify the precise user context.\n - The user agent details in the `user_agent.original` field may also indicate what kind of a client made the request.\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 might indicate the source of the program or the nature of its tasks.\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- False positives can occur if activity is coming from new employees based in a country with no previous history in AWS.\n- Examine the history of the command. If the command only manifested recently, it might be part of a new automation module or script. If it has a consistent cadence (for example, it appears in small numbers on a weekly or monthly cadence), it might be part of a housekeeping or maintenance process. You can find the command in the `event.action field` field.\n\n### Related Rules\n\n- Unusual City For an AWS Command - 809b70d3-e2c3-455e-af1b-2626a5a1a276\n- Unusual AWS Command for a User - ac706eae-d5ec-4b14-b4fd-e8ba8086f0e1\n- Rare AWS Error Code - 19de8096-e2b0-4bd8-80c9-34a820813fff\n- Spike in AWS Error Messages - 78d3d8d9-b476-451d-a9e0-7a5addd70670\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", + "references": [ + "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html" + ], + "related_integrations": [ + { + "package": "aws", + "version": "^2.0.0" + } + ], + "risk_score": 21, + "rule_id": "dca28dee-c999-400f-b640-50a081cc0fd1", + "setup": "## Setup\n\nThis rule requires the installation of associated Machine Learning jobs, as well as data coming in from AWS.\n\n### Anomaly Detection Setup\n\nOnce the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the \"Definition\" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).\n\n### AWS Integration Setup\nThe AWS integration allows you to collect logs and metrics from Amazon Web Services (AWS) with Elastic Agent.\n\n#### The following steps should be executed in order to add the Elastic Agent System integration \"aws\" to your system:\n- Go to the Kibana home page and click \u201cAdd integrations\u201d.\n- In the query bar, search for \u201cAWS\u201d and select the integration to see more details about it.\n- Click \u201cAdd AWS\u201d.\n- Configure the integration name and optionally add a description.\n- Review optional and advanced settings accordingly.\n- Add the newly installed \u201caws\u201d to an existing or a new agent policy, and deploy the agent on your system from which aws log files are desirable.\n- Click \u201cSave and Continue\u201d.\n- For more details on the integration refer to the [helper guide](https://www.elastic.co/docs/current/integrations/aws).\n", + "severity": "low", + "tags": [ + "Domain: Cloud", + "Data Source: AWS", + "Data Source: Amazon Web Services", + "Rule Type: ML", + "Rule Type: Machine Learning", + "Resources: Investigation Guide" + ], + "type": "machine_learning", + "version": 209 + }, + "id": "dca28dee-c999-400f-b640-50a081cc0fd1_209", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/df197323-72a8-46a9-a08e-3f5b04a4a97a_104.json b/packages/security_detection_engine/kibana/security_rule/df197323-72a8-46a9-a08e-3f5b04a4a97a_104.json new file mode 100644 index 00000000000..619c3d0fa64 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/df197323-72a8-46a9-a08e-3f5b04a4a97a_104.json @@ -0,0 +1,69 @@ +{ + "attributes": { + "anomaly_threshold": 75, + "author": [ + "Elastic" + ], + "description": "Looks for anomalous access to the cloud platform metadata service by an unusual user. The metadata service may be targeted in order to harvest credentials or user data scripts containing secrets.", + "false_positives": [ + "A newly installed program, or one that runs under a new or rarely used user context, could trigger this detection rule. Manual interrogation of the metadata service during debugging or troubleshooting could trigger this rule." + ], + "from": "now-45m", + "interval": "15m", + "license": "Elastic License v2", + "machine_learning_job_id": [ + "v3_windows_rare_metadata_user" + ], + "name": "Unusual Windows User Calling the Metadata Service", + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "windows", + "version": "^1.5.0" + } + ], + "risk_score": 21, + "rule_id": "df197323-72a8-46a9-a08e-3f5b04a4a97a", + "setup": "## Setup\n\nThis rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:\n- Elastic Defend\n- Windows\n\n### Anomaly Detection Setup\n\nOnce the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the \"Definition\" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).\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 to your 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/current/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\n### Windows Integration Setup\nThe Windows integration allows you to monitor the Windows OS, services, applications, and more.\n\n#### The following steps should be executed in order to add the Elastic Agent System integration \"windows\" to your system:\n- Go to the Kibana home page and click \u201cAdd integrations\u201d.\n- In the query bar, search for \u201cWindows\u201d and select the integration to see more details about it.\n- Click \u201cAdd Windows\u201d.\n- Configure the integration name and optionally add a description.\n- Review optional and advanced settings accordingly.\n- Add the newly installed \u201cwindows\u201d to an existing or a new agent policy, and deploy the agent on your system from which windows log files are desirable.\n- Click \u201cSave and Continue\u201d.\n- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/windows).\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Windows", + "Use Case: Threat Detection", + "Rule Type: ML", + "Rule Type: Machine Learning", + "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/" + } + ] + } + ] + } + ], + "type": "machine_learning", + "version": 104 + }, + "id": "df197323-72a8-46a9-a08e-3f5b04a4a97a_104", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/e26aed74-c816-40d3-a810-48d6fbd8b2fd_105.json b/packages/security_detection_engine/kibana/security_rule/e26aed74-c816-40d3-a810-48d6fbd8b2fd_105.json new file mode 100644 index 00000000000..3c3285f70ff --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/e26aed74-c816-40d3-a810-48d6fbd8b2fd_105.json @@ -0,0 +1,96 @@ +{ + "attributes": { + "anomaly_threshold": 75, + "author": [ + "Elastic" + ], + "description": "A machine learning job found an unusually large spike in successful authentication events from a particular source IP address. This can be due to password spraying, user enumeration or brute force activity.", + "false_positives": [ + "Build servers and CI systems can sometimes trigger this alert. Security test cycles that include brute force or password spraying activities may trigger this alert." + ], + "from": "now-30m", + "interval": "15m", + "license": "Elastic License v2", + "machine_learning_job_id": "auth_high_count_logon_events_for_a_source_ip", + "name": "Spike in Successful Logon Events from a Source IP", + "note": "## Triage and analysis\n\n### Investigating Spike in Successful Logon Events from a Source IP\n\nThis rule uses a machine learning job to detect a substantial spike in successful authentication events. This could indicate post-exploitation activities that aim to test which hosts, services, and other resources the attacker can access with the compromised credentials.\n\n#### Possible investigation steps\n\n- Identify the specifics of the involved assets, such as role, criticality, and associated users.\n- Check if the authentication comes from different sources.\n- Use the historical data available to determine if the same behavior happened in the past.\n- Investigate other alerts associated with the involved users during the past 48 hours.\n- Check whether the involved credentials are used in automation or scheduled tasks.\n- If this activity is suspicious, contact the account owner and confirm whether they are aware of it.\n\n### False positive analysis\n\n- Understand the context of the authentications by contacting the asset owners. If this activity is related to a new business process or newly implemented (approved) technology, consider adding exceptions \u2014 preferably with a combination of user and source conditions.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the 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- 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", + "references": [ + "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html" + ], + "related_integrations": [ + { + "package": "auditd_manager", + "version": "^1.0.0" + }, + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "system", + "version": "^1.6.4" + } + ], + "risk_score": 21, + "rule_id": "e26aed74-c816-40d3-a810-48d6fbd8b2fd", + "setup": "## Setup\n\nThis rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:\n- Elastic Defend\n- Auditd Manager\n- System\n\n### Anomaly Detection Setup\n\nOnce the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the \"Definition\" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).\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 to your 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/current/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\n### Auditd Manager Integration Setup\nThe Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel.\nAuditd Manager 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.\n\n#### The following steps should be executed in order to add the Elastic Agent System integration \"auditd_manager\" to your system:\n- Go to the Kibana home page and click \u201cAdd integrations\u201d.\n- In the query bar, search for \u201cAuditd Manager\u201d and select the integration to see more details about it.\n- Click \u201cAdd Auditd Manager\u201d.\n- Configure the integration name and optionally add a description.\n- Review optional and advanced settings accordingly.\n- Add the newly installed \u201cauditd manager\u201d to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable.\n- Click \u201cSave and Continue\u201d.\n- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/auditd_manager).\n\n#### Rule Specific Setup Note\nAuditd Manager subscribes to the kernel and receives events as they occur without any additional configuration.\nHowever, 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.\n- For this detection rule no additional audit rules are required.\n\n### System Integration Setup\nThe System integration allows you to collect system logs and metrics from your servers with Elastic Agent.\n\n#### The following steps should be executed in order to add the Elastic Agent System integration \"system\" to your system:\n- Go to the Kibana home page and click \u201cAdd integrations\u201d.\n- In the query bar, search for \u201cSystem\u201d and select the integration to see more details about it.\n- Click \u201cAdd System\u201d.\n- Configure the integration name and optionally add a description.\n- Review optional and advanced settings accordingly.\n- Add the newly installed \u201csystem\u201d to an existing or a new agent policy, and deploy the agent on your system from which system log files are desirable.\n- Click \u201cSave and Continue\u201d.\n- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/system).\n", + "severity": "low", + "tags": [ + "Use Case: Identity and Access Audit", + "Use Case: Threat Detection", + "Rule Type: ML", + "Rule Type: Machine Learning", + "Tactic: Credential Access", + "Tactic: Defense Evasion", + "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/" + } + ] + }, + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0005", + "name": "Defense Evasion", + "reference": "https://attack.mitre.org/tactics/TA0005/" + }, + "technique": [ + { + "id": "T1078", + "name": "Valid Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/", + "subtechnique": [ + { + "id": "T1078.002", + "name": "Domain Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/002/" + }, + { + "id": "T1078.003", + "name": "Local Accounts", + "reference": "https://attack.mitre.org/techniques/T1078/003/" + } + ] + } + ] + } + ], + "type": "machine_learning", + "version": 105 + }, + "id": "e26aed74-c816-40d3-a810-48d6fbd8b2fd_105", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/eaa77d63-9679-4ce3-be25-3ba8b795e5fa_104.json b/packages/security_detection_engine/kibana/security_rule/eaa77d63-9679-4ce3-be25-3ba8b795e5fa_104.json new file mode 100644 index 00000000000..4ad83d95a16 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/eaa77d63-9679-4ce3-be25-3ba8b795e5fa_104.json @@ -0,0 +1,43 @@ +{ + "attributes": { + "anomaly_threshold": 75, + "author": [ + "Elastic" + ], + "description": "A machine learning job detected an unusually large spike in network traffic that was denied by network access control lists (ACLs) or firewall rules. Such a burst of denied traffic is usually caused by either 1) a mis-configured application or firewall or 2) suspicious or malicious activity. Unsuccessful attempts at network transit, in order to connect to command-and-control (C2), or engage in data exfiltration, may produce a burst of failed connections. This could also be due to unusually large amounts of reconnaissance or enumeration traffic. Denial-of-service attacks or traffic floods may also produce such a surge in traffic.", + "false_positives": [ + "A misconfgured network application or firewall may trigger this alert. Security scans or test cycles may trigger this alert." + ], + "from": "now-30m", + "interval": "15m", + "license": "Elastic License v2", + "machine_learning_job_id": "high_count_network_denies", + "name": "Spike in Firewall Denies", + "references": [ + "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html" + ], + "related_integrations": [ + { + "package": "endpoint", + "version": "^8.2.0" + }, + { + "package": "network_traffic", + "version": "^1.1.0" + } + ], + "risk_score": 21, + "rule_id": "eaa77d63-9679-4ce3-be25-3ba8b795e5fa", + "setup": "## Setup\n\nThis rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:\n- Elastic Defend\n- Network Packet Capture\n\n### Anomaly Detection Setup\n\nOnce the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the \"Definition\" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).\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 to your 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/current/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\n### Network Packet Capture Integration Setup\nThe Network Packet Capture integration sniffs network packets on a host and dissects known protocols. Monitoring the network traffic is critical to gaining observability and securing your environment \u2014 ensuring high levels of performance and security. The Network Packet Capture integration captures the network traffic between your application servers, decodes common application layer protocols and records the interesting fields for each transaction.\n\n#### The following steps should be executed in order to add the Elastic Agent System integration \"network_traffic\" to your system:\n- Go to the Kibana home page and click \u201cAdd integrations\u201d.\n- In the query bar, search for \u201cNetwork Packet Capture\u201d and select the integration to see more details about it.\n- Click \u201cAdd Network Packet Capture\u201d.\n- Configure the integration name and optionally add a description.\n- Review optional and advanced settings accordingly.\n- Add the newly installed \u201cnetwork_traffic\u201d to an existing or a new agent policy, and deploy the agent on your system from which network log files are desirable.\n- Click \u201cSave and Continue\u201d.\n- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/network_traffic).\n", + "severity": "low", + "tags": [ + "Use Case: Threat Detection", + "Rule Type: ML", + "Rule Type: Machine Learning" + ], + "type": "machine_learning", + "version": 104 + }, + "id": "eaa77d63-9679-4ce3-be25-3ba8b795e5fa_104", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/f3e22c8b-ea47-45d1-b502-b57b6de950b3_7.json b/packages/security_detection_engine/kibana/security_rule/f3e22c8b-ea47-45d1-b502-b57b6de950b3_7.json new file mode 100644 index 00000000000..574a8f8921c --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/f3e22c8b-ea47-45d1-b502-b57b6de950b3_7.json @@ -0,0 +1,137 @@ +{ + "attributes": { + "author": [ + "Elastic" + ], + "description": "This rule is triggered when a URL indicator from the Threat Intel Filebeat module or integrations has a match against an event that contains URL data, like DNS events, network logs, etc.", + "from": "now-65m", + "index": [ + "auditbeat-*", + "endgame-*", + "filebeat-*", + "logs-*", + "packetbeat-*", + "winlogbeat-*" + ], + "interval": "1h", + "language": "kuery", + "license": "Elastic License v2", + "name": "Threat Intel URL Indicator Match", + "note": "## Triage and Analysis\n\n### Investigating Threat Intel URL Indicator Match\n\nThreat Intel indicator match rules allow matching from a local observation, such as an endpoint event that records a file hash with an entry of a file hash stored within the Threat Intel integrations index.\n\nMatches are based on threat intelligence data that's been ingested during the last 30 days. Some integrations don't place expiration dates on their threat indicators, so we strongly recommend validating ingested threat indicators and reviewing match results. When reviewing match results, check associated activity to determine whether the event requires additional investigation.\n\nThis rule is triggered when a URL indicator from the Threat Intel Filebeat module or a threat intelligence integration matches against an event that contains URL data, like DNS events, network logs, etc.\n\n> **Note**:\n> This investigation guide uses the [Osquery Markdown Plugin](https://www.elastic.co/guide/en/security/master/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 URL, which can be found in the `threat.indicator.matched.atomic` field:\n - Identify the type of malicious activity related to the URL (phishing, malware, etc.).\n - Check the reputation of the IP address in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.\n - Execute a WHOIS lookup to retrieve information about the domain registration and contacts to report abuse.\n - If dealing with a phishing incident:\n - Contact the user to gain more information around the delivery method, information sent, etc.\n - Analyze whether the URL is trying to impersonate a legitimate address. Look for typosquatting, extra or unusual subdomains, or other anomalies that could lure the user.\n - Investigate the phishing page to identify which information may have been sent to the attacker by the user.\n- Identify the process responsible for the connection, and 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- Retrieve the involved process executable and 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- Using the data collected through the analysis, scope users targeted and other machines infected in the environment.\n\n### False Positive Analysis\n\n- False positives might occur after large and publicly written campaigns if curious employees interact with attacker infrastructure.\n- Some feeds may include internal or known benign addresses by mistake (e.g., 8.8.8.8, google.com, 127.0.0.1, etc.). Make sure you understand how blocking a specific domain or address might impact the organization or normal system functioning.\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- Consider reporting the address for abuse using the provided contact information.\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": "url.full:*\n", + "references": [ + "https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-threatintel.html", + "https://www.elastic.co/guide/en/security/master/es-threat-intel-integrations.html", + "https://www.elastic.co/security/tip" + ], + "required_fields": [ + { + "ecs": true, + "name": "url.full", + "type": "wildcard" + } + ], + "risk_score": 99, + "rule_id": "f3e22c8b-ea47-45d1-b502-b57b6de950b3", + "setup": "## Setup\n\nThis rule needs threat intelligence indicators to work.\nThreat intelligence indicators can be collected using an [Elastic Agent integration](https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html#agent-ti-integration),\nthe [Threat Intel module](https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html#ti-mod-integration),\nor a [custom integration](https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html#custom-ti-integration).\n\nMore information can be found [here](https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html).\n", + "severity": "critical", + "tags": [ + "OS: Windows", + "Data Source: Elastic Endgame", + "Rule Type: Threat Match" + ], + "threat_filters": [ + { + "$state": { + "store": "appState" + }, + "meta": { + "disabled": false, + "key": "event.category", + "negate": false, + "params": { + "query": "threat" + }, + "type": "phrase" + }, + "query": { + "match_phrase": { + "event.category": "threat" + } + } + }, + { + "$state": { + "store": "appState" + }, + "meta": { + "disabled": false, + "key": "event.kind", + "negate": false, + "params": { + "query": "enrichment" + }, + "type": "phrase" + }, + "query": { + "match_phrase": { + "event.kind": "enrichment" + } + } + }, + { + "$state": { + "store": "appState" + }, + "meta": { + "disabled": false, + "key": "event.type", + "negate": false, + "params": { + "query": "indicator" + }, + "type": "phrase" + }, + "query": { + "match_phrase": { + "event.type": "indicator" + } + } + } + ], + "threat_index": [ + "filebeat-*", + "logs-ti_*" + ], + "threat_indicator_path": "threat.indicator", + "threat_language": "kuery", + "threat_mapping": [ + { + "entries": [ + { + "field": "url.full", + "type": "mapping", + "value": "threat.indicator.url.full" + } + ] + }, + { + "entries": [ + { + "field": "url.original", + "type": "mapping", + "value": "threat.indicator.url.original" + } + ] + } + ], + "threat_query": "@timestamp >= \"now-30d/d\" and event.module:(threatintel or ti_*) and threat.indicator.url.full:* and not labels.is_ioc_transform_source:\"true\"", + "timeline_id": "495ad7a7-316e-4544-8a0f-9c098daee76e", + "timeline_title": "Generic Threat Match Timeline", + "timestamp_override": "event.ingested", + "type": "threat_match", + "version": 7 + }, + "id": "f3e22c8b-ea47-45d1-b502-b57b6de950b3_7", + "type": "security-rule" +} \ No newline at end of file diff --git a/packages/security_detection_engine/kibana/security_rule/f9590f47-6bd5-4a49-bd49-a2f886476fb9_105.json b/packages/security_detection_engine/kibana/security_rule/f9590f47-6bd5-4a49-bd49-a2f886476fb9_105.json new file mode 100644 index 00000000000..cfb6e3b2763 --- /dev/null +++ b/packages/security_detection_engine/kibana/security_rule/f9590f47-6bd5-4a49-bd49-a2f886476fb9_105.json @@ -0,0 +1,62 @@ +{ + "attributes": { + "anomaly_threshold": 25, + "author": [ + "Elastic" + ], + "description": "Looks for commands related to system network configuration discovery from an unusual user context. This can be due to uncommon troubleshooting activity or due to a compromised account. A compromised account may be used by a threat actor to engage in system network configuration discovery in order to increase their understanding of connected networks and hosts. This information may be used to shape follow-up behaviors such as lateral movement or additional discovery.", + "false_positives": [ + "Uncommon user command activity can be due to an engineer logging onto a server instance in order to perform manual troubleshooting or reconfiguration." + ], + "from": "now-45m", + "interval": "15m", + "license": "Elastic License v2", + "machine_learning_job_id": [ + "v3_linux_network_configuration_discovery" + ], + "name": "Unusual Linux Network Configuration Discovery", + "related_integrations": [ + { + "package": "auditd_manager", + "version": "^1.0.0" + }, + { + "package": "endpoint", + "version": "^8.2.0" + } + ], + "risk_score": 21, + "rule_id": "f9590f47-6bd5-4a49-bd49-a2f886476fb9", + "setup": "## Setup\n\nThis rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:\n- Elastic Defend\n- Auditd Manager\n\n### Anomaly Detection Setup\n\nOnce the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the \"Definition\" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).\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 to your 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/current/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\n### Auditd Manager Integration Setup\nThe Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel.\nAuditd Manager 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.\n\n#### The following steps should be executed in order to add the Elastic Agent System integration \"auditd_manager\" to your system:\n- Go to the Kibana home page and click \u201cAdd integrations\u201d.\n- In the query bar, search for \u201cAuditd Manager\u201d and select the integration to see more details about it.\n- Click \u201cAdd Auditd Manager\u201d.\n- Configure the integration name and optionally add a description.\n- Review optional and advanced settings accordingly.\n- Add the newly installed \u201cauditd manager\u201d to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable.\n- Click \u201cSave and Continue\u201d.\n- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/auditd_manager).\n\n#### Rule Specific Setup Note\nAuditd Manager subscribes to the kernel and receives events as they occur without any additional configuration.\nHowever, 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.\n- For this detection rule no additional audit rules are required.\n", + "severity": "low", + "tags": [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Rule Type: ML", + "Rule Type: Machine Learning", + "Tactic: Discovery" + ], + "threat": [ + { + "framework": "MITRE ATT&CK", + "tactic": { + "id": "TA0007", + "name": "Discovery", + "reference": "https://attack.mitre.org/tactics/TA0007/" + }, + "technique": [ + { + "id": "T1016", + "name": "System Network Configuration Discovery", + "reference": "https://attack.mitre.org/techniques/T1016/" + } + ] + } + ], + "type": "machine_learning", + "version": 105 + }, + "id": "f9590f47-6bd5-4a49-bd49-a2f886476fb9_105", + "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 abe87f65fe8..366892ed695 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: 8.14.3 +version: 8.14.4-beta.1 From 21b957bed83b2293b2fb083042e5bd1be22ffa40 Mon Sep 17 00:00:00 2001 From: protectionsmachine <72879786+protectionsmachine@users.noreply.github.com> Date: Tue, 25 Jun 2024 12:49:01 +0000 Subject: [PATCH 2/2] Add changelog entry for 8.14.4-beta.1 --- packages/security_detection_engine/changelog.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/packages/security_detection_engine/changelog.yml b/packages/security_detection_engine/changelog.yml index b4a6d8f8dad..9d6ec7e5784 100644 --- a/packages/security_detection_engine/changelog.yml +++ b/packages/security_detection_engine/changelog.yml @@ -4,7 +4,7 @@ changes: - description: Release security rules update type: enhancement - link: https://github.com/elastic/integrations/pulls/0000 + link: https://github.com/elastic/integrations/pull/10239 - version: 8.14.3 changes: - description: Release security rules update