diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-agent-spoofing-multiple-hosts-using-same-agent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-agent-spoofing-multiple-hosts-using-same-agent.asciidoc new file mode 100644 index 0000000000..b9d1729b70 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-agent-spoofing-multiple-hosts-using-same-agent.asciidoc @@ -0,0 +1,58 @@ +[[prebuilt-rule-8-13-10-agent-spoofing-multiple-hosts-using-same-agent]] +=== Agent Spoofing - Multiple Hosts Using Same Agent + +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. + +*Rule type*: threshold + +*Rule indices*: + +* logs-* +* metrics-* +* traces-* + +*Severity*: high + +*Risk score*: 73 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Use Case: Threat Detection +* Tactic: Defense Evasion + +*Version*: 102 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Rule query + + +[source, js] +---------------------------------- +event.agent_id_status:* and not tags:forwarded + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Masquerading +** ID: T1036 +** Reference URL: https://attack.mitre.org/techniques/T1036/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-anomalous-linux-compiler-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-anomalous-linux-compiler-activity.asciidoc new file mode 100644 index 0000000000..88481fc0b9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-anomalous-linux-compiler-activity.asciidoc @@ -0,0 +1,123 @@ +[[prebuilt-rule-8-13-10-anomalous-linux-compiler-activity]] +=== Anomalous Linux Compiler Activity + +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. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-45m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Resource Development + +*Version*: 104 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Auditd Manager + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditd Manager Integration Setup* + +The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel. +Auditd 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. + + +*The following steps should be executed in order to add the Elastic Agent System integration "auditd_manager" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Auditd Manager” and select the integration to see more details about it. +- Click “Add Auditd Manager”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “auditd manager” to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/auditd_manager[helper guide]. + + +*Rule Specific Setup Note* + +Auditd Manager subscribes to the kernel and receives events as they occur without any additional configuration. +However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from. +- For this detection rule no additional audit rules are required. + + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Resource Development +** ID: TA0042 +** Reference URL: https://attack.mitre.org/tactics/TA0042/ +* Technique: +** Name: Obtain Capabilities +** ID: T1588 +** Reference URL: https://attack.mitre.org/techniques/T1588/ +* Sub-technique: +** Name: Malware +** ID: T1588.001 +** Reference URL: https://attack.mitre.org/techniques/T1588/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-anomalous-process-for-a-linux-population.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-anomalous-process-for-a-linux-population.asciidoc new file mode 100644 index 0000000000..9f7f3afda2 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-anomalous-process-for-a-linux-population.asciidoc @@ -0,0 +1,177 @@ +[[prebuilt-rule-8-13-10-anomalous-process-for-a-linux-population]] +=== Anomalous Process For a Linux Population + +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. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-45m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 105 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Anomalous Process For a Linux Population* + + +Searching 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. + +This 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. + + +*Possible investigation steps* + + +- 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. +- Investigate other alerts associated with the user/host during the past 48 hours. +- 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? +- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations. +- 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. +- 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. + + +*False Positive Analysis* + + +- If this activity is related to new benign software installation activity, consider adding exceptions — preferably with a combination of user and command line conditions. +- 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. + + +*Response and Remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved hosts to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- 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. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- 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). + + +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Auditd Manager + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditd Manager Integration Setup* + +The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel. +Auditd 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. + + +*The following steps should be executed in order to add the Elastic Agent System integration "auditd_manager" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Auditd Manager” and select the integration to see more details about it. +- Click “Add Auditd Manager”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “auditd manager” to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/auditd_manager[helper guide]. + + +*Rule Specific Setup Note* + +Auditd Manager subscribes to the kernel and receives events as they occur without any additional configuration. +However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from. +- For this detection rule no additional audit rules are required. + + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Sub-technique: +** Name: Windows Service +** ID: T1543.003 +** Reference URL: https://attack.mitre.org/techniques/T1543/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-anomalous-process-for-a-windows-population.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-anomalous-process-for-a-windows-population.asciidoc new file mode 100644 index 0000000000..64e47311a0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-anomalous-process-for-a-windows-population.asciidoc @@ -0,0 +1,203 @@ +[[prebuilt-rule-8-13-10-anomalous-process-for-a-windows-population]] +=== Anomalous Process For a Windows Population + +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. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-45m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Persistence +* Tactic: Execution + +*Version*: 106 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Anomalous Process For a Windows Population* + + +Searching 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. + +This 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. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- 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. + - 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. + - Investigate the process metadata — such as the digital signature, directory, etc. — to obtain more context that can indicate whether the executable is associated with an expected software vendor or package. +- Investigate other alerts associated with the user/host during the past 48 hours. +- 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? +- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations. +- 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. +- 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. +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze the process executable using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{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"}} + - !{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"}} + - 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. + + +*False Positive Analysis* + + +- If this activity is related to new benign software installation activity, consider adding exceptions — preferably with a combination of user and command line conditions. +- 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. + + +*Related Rules* + + +- Unusual Process For a Windows Host - 6d448b96-c922-4adb-b51c-b767f1ea5b76 +- Unusual Windows Path Activity - 445a342e-03fb-42d0-8656-0367eb2dead5 +- Unusual Windows Process Calling the Metadata Service - abae61a8-c560-4dbd-acca-1e1438bff36b + + +*Response and Remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved hosts to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- 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. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- 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). + + +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Windows + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Windows Integration Setup* + +The Windows integration allows you to monitor the Windows OS, services, applications, and more. + + +*The following steps should be executed in order to add the Elastic Agent System integration "windows" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Windows” and select the integration to see more details about it. +- Click “Add Windows”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “windows” to an existing or a new agent policy, and deploy the agent on your system from which windows log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/windows[helper guide]. + + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: User Execution +** ID: T1204 +** Reference URL: https://attack.mitre.org/techniques/T1204/ +* Sub-technique: +** Name: Malicious File +** ID: T1204.002 +** Reference URL: https://attack.mitre.org/techniques/T1204/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-anomalous-windows-process-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-anomalous-windows-process-creation.asciidoc new file mode 100644 index 0000000000..736d2838cc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-anomalous-windows-process-creation.asciidoc @@ -0,0 +1,191 @@ +[[prebuilt-rule-8-13-10-anomalous-windows-process-creation]] +=== Anomalous Windows Process Creation + +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. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-45m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 106 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Anomalous Windows Process Creation* + + +Searching 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. + +This 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. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- 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. + - 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. + - Investigate the process metadata — such as the digital signature, directory, etc. — to obtain more context that can indicate whether the executable is associated with an expected software vendor or package. +- Investigate other alerts associated with the user/host during the past 48 hours. +- 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? +- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations. +- 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. +- 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. +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze the process executable using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{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"}} + - !{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"}} + - 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. + + +*False Positive Analysis* + + +- If this activity is related to new benign software installation activity, consider adding exceptions — preferably with a combination of user and command line conditions. +- 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. + + +*Related Rules* + + +- Unusual Process For a Windows Host - 6d448b96-c922-4adb-b51c-b767f1ea5b76 +- Unusual Windows Path Activity - 445a342e-03fb-42d0-8656-0367eb2dead5 +- Unusual Windows Process Calling the Metadata Service - abae61a8-c560-4dbd-acca-1e1438bff36b + + +*Response and Remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved hosts to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- 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. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- 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). + + +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Windows + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Windows Integration Setup* + +The Windows integration allows you to monitor the Windows OS, services, applications, and more. + + +*The following steps should be executed in order to add the Elastic Agent System integration "windows" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Windows” and select the integration to see more details about it. +- Click “Add Windows”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “windows” to an existing or a new agent policy, and deploy the agent on your system from which windows log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/windows[helper guide]. + + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-aws-iam-user-created-access-keys-for-another-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-aws-iam-user-created-access-keys-for-another-user.asciidoc new file mode 100644 index 0000000000..ae10cc2cd9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-aws-iam-user-created-access-keys-for-another-user.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-13-10-aws-iam-user-created-access-keys-for-another-user]] +=== AWS IAM User Created Access Keys For Another User + +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. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-10m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*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 + +*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 + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM User Created Access Keys For Another User* + + +AWS access keys created for IAM users or root user are long-term credentials that provide programatic access to AWS. +With access to the `iam:CreateAccessKey` permission, a set of compromised credentials could be used to create a new +set of credentials for another user for privilege escalation or as a means of persistence. This rule uses https://www.elastic.co/guide/en/security/master/rules-ui-create.html#create-esql-rule[ES|QL] +to look for use of the `CreateAccessKey` operation where the user.name is different from the user.target.name. + + + +*Possible investigation steps* + + +- Identify both related accounts and their role in the environment. +- Review IAM permission policies for the user identities. +- Identify the applications or users that should use these accounts. +- Investigate other alerts associated with the accounts during the past 48 hours. +- 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. +- Contact the account owners and confirm whether they are aware of this activity. +- Considering the source IP address and geolocation of the user who issued the command: + - Do they look normal for the calling user? + - 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? + - 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? +- 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. + - Determine what other API calls were made by the user. + - Assess whether this behavior is prevalent in the environment by looking for similar occurrences involving other users. + + +*False positive analysis* + + +- 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. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. + - Rotate user credentials + - Remove the newly created credentials from the affected user(s) +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. + - Rotate secrets 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. +- Remove unauthorized new accounts, and request password resets for other IAM users. +- Consider enabling multi-factor authentication for users. +- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. +- Implement security best practices https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[outlined] by AWS. +- Take the actions needed to return affected systems, data, or services to their normal operational levels. +- Identify the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- 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). + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-aws.cloudtrail-* +| where event.provider == "iam.amazonaws.com" and event.action == "CreateAccessKey" and event.outcome == "success" and user.name != user.target.name + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Credentials +** ID: T1098.001 +** Reference URL: https://attack.mitre.org/techniques/T1098/001/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Credentials +** ID: T1098.001 +** Reference URL: https://attack.mitre.org/techniques/T1098/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-aws-security-token-service-sts-assumerole-usage.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-aws-security-token-service-sts-assumerole-usage.asciidoc new file mode 100644 index 0000000000..180ea3b851 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-aws-security-token-service-sts-assumerole-usage.asciidoc @@ -0,0 +1,86 @@ +[[prebuilt-rule-8-13-10-aws-security-token-service-sts-assumerole-usage]] +=== AWS Security Token Service (STS) AssumeRole Usage + +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. + +*Rule type*: query + +*Rule indices*: + +* filebeat-* +* logs-aws.cloudtrail-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: None ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Data Source: AWS STS +* Use Case: Identity and Access Audit +* Tactic: Privilege Escalation + +*Version*: 207 + +*Rule authors*: + +* Austin Songer + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + + +==== Setup + + +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +event.dataset:aws.cloudtrail and event.provider:sts.amazonaws.com and event.action:AssumeRole and +aws.cloudtrail.user_identity.session_context.session_issuer.type:Role and event.outcome:success + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Tactic: +** Name: Lateral Movement +** ID: TA0008 +** Reference URL: https://attack.mitre.org/tactics/TA0008/ +* Technique: +** Name: Use Alternate Authentication Material +** ID: T1550 +** Reference URL: https://attack.mitre.org/techniques/T1550/ +* Sub-technique: +** Name: Application Access Token +** ID: T1550.001 +** Reference URL: https://attack.mitre.org/techniques/T1550/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-dns-global-query-block-list-modified-or-disabled.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-dns-global-query-block-list-modified-or-disabled.asciidoc new file mode 100644 index 0000000000..58b02dca7d --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-dns-global-query-block-list-modified-or-disabled.asciidoc @@ -0,0 +1,81 @@ +[[prebuilt-rule-8-13-10-dns-global-query-block-list-modified-or-disabled]] +=== DNS Global Query Block List Modified or Disabled + +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. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.registry-* +* logs-windows.sysmon_operational-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*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/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: Sysmon + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type : "change" and +( + (registry.value : "EnableGlobalQueryBlockList" and registry.data.strings : ("0", "0x00000000")) or + (registry.value : "GlobalQueryBlockList" and not registry.data.strings : "wpad") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Adversary-in-the-Middle +** ID: T1557 +** Reference URL: https://attack.mitre.org/techniques/T1557/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-dns-tunneling.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-dns-tunneling.asciidoc new file mode 100644 index 0000000000..0eeba3c7bb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-dns-tunneling.asciidoc @@ -0,0 +1,111 @@ +[[prebuilt-rule-8-13-10-dns-tunneling]] +=== DNS Tunneling + +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. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-45m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html + +*Tags*: + +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Command and Control + +*Version*: 104 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Network Packet Capture + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Network Packet Capture Integration Setup* + +The 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 — 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. + + +*The following steps should be executed in order to add the Elastic Agent System integration "network_traffic" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Network Packet Capture” and select the integration to see more details about it. +- Click “Add Network Packet Capture”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “network_traffic” to an existing or a new agent policy, and deploy the agent on your system from which network log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/network_traffic[helper guide]. + + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Protocol Tunneling +** ID: T1572 +** Reference URL: https://attack.mitre.org/techniques/T1572/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-high-number-of-okta-device-token-cookies-generated-for-authentication.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-high-number-of-okta-device-token-cookies-generated-for-authentication.asciidoc new file mode 100644 index 0000000000..24a52cf020 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-high-number-of-okta-device-token-cookies-generated-for-authentication.asciidoc @@ -0,0 +1,152 @@ +[[prebuilt-rule-8-13-10-high-number-of-okta-device-token-cookies-generated-for-authentication]] +=== High Number of Okta Device Token Cookies Generated for Authentication + +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. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*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/ + +*Tags*: + +* Use Case: Identity and Access Audit +* Data Source: Okta +* Tactic: Credential Access + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating High Number of Okta Device Token Cookies Generated for Authentication* + + +This 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. + + +*Possible investigation steps:* + +- 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. +- 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. +- 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. +- Review the `okta.security_context.is_proxy` field to determine if the device is a proxy. + - If the device is a proxy, this may indicate that a user is using a proxy to access multiple accounts for password spraying. +- With the list of `okta.actor.alternate_id` values, review `event.outcome` results to determine if the authentication was successful. + - If the authentication was successful for any user, pivoting to `event.action` values for those users may provide additional context. +- With Okta end users identified, review the `okta.debug_context.debug_data.dt_hash` field. + - Historical analysis should indicate if this device token hash is commonly associated with the user. +- Review the `okta.event_type` field to determine the type of authentication event that occurred. + - If the event type is `user.authentication.sso`, the user may have legitimately started a session via a proxy for security or privacy reasons. + - If the event type is `user.authentication.password`, the user may be using a proxy to access multiple accounts for password spraying. + - If the event type is `user.session.start`, the source may have attempted to establish a session via the Okta authentication API. +- Examine the `okta.outcome.result` field to determine if the authentication was successful. +- Review the past activities of the actor(s) involved in this action by checking their previous actions. +- 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. + - This may help determine the authentication and authorization actions that occurred between the user, Okta and application. + + +*False positive analysis:* + +- A user may have legitimately started a session via a proxy for security or privacy reasons. +- Users may share an endpoint related to work or personal use in which separate Okta accounts are used. + - Architecturally, this shared endpoint may leverage a proxy for security or privacy reasons. + - Shared systems such as Kiosks and conference room computers may be used by multiple users. + - Shared working spaces may have a single endpoint that is used by multiple users. + + +*Response and remediation:* + +- Review the profile of the users involved in this action to determine if proxy usage may be expected. +- If the user is legitimate and the authentication behavior is not suspicious based on device analysis, no action is required. +- If the user is legitimate but the authentication behavior is suspicious, consider resetting passwords for the users involves and enabling multi-factor authentication (MFA). + - If MFA is already enabled, consider resetting MFA for the users. +- If any of the users are not legitimate, consider deactivating the user's account. +- Conduct a review of Okta policies and ensure they are in accordance with security best practices. +- Check with internal IT teams to determine if the accounts involved recently had MFA reset at the request of the user. + - If so, confirm with the user this was a legitimate request. + - If so and this was not a legitimate request, consider deactivating the user's account temporarily. + - Reset passwords and reset MFA for the user. +- If this is a false positive, consider adding the `okta.debug_context.debug_data.dt_hash` field to the `exceptions` list in the rule. + - This will prevent future occurrences of this event for this device from triggering the rule. + - Alternatively adding `okta.client.ip` or a CIDR range to the `exceptions` list can prevent future occurrences of this event from triggering the rule. + - This should be done with caution as it may prevent legitimate alerts from being generated. + + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-okta* +| WHERE + event.dataset == "okta.system" + AND (event.action RLIKE "user\\.authentication(.*)" OR event.action == "user.session.start") + AND okta.debug_context.debug_data.request_uri == "/api/v1/authn" + AND okta.outcome.reason == "INVALID_CREDENTIALS" +| STATS + source_auth_count = COUNT_DISTINCT(okta.debug_context.debug_data.dt_hash) + BY okta.client.ip, okta.actor.alternate_id +| WHERE + source_auth_count >= 30 +| SORT + source_auth_count DESC + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Credential Stuffing +** ID: T1110.004 +** Reference URL: https://attack.mitre.org/techniques/T1110/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-multiple-okta-user-authentication-events-with-client-address.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-multiple-okta-user-authentication-events-with-client-address.asciidoc new file mode 100644 index 0000000000..5fff6b5074 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-multiple-okta-user-authentication-events-with-client-address.asciidoc @@ -0,0 +1,151 @@ +[[prebuilt-rule-8-13-10-multiple-okta-user-authentication-events-with-client-address]] +=== Multiple Okta User Authentication Events with Client Address + +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. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*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/ + +*Tags*: + +* Use Case: Identity and Access Audit +* Data Source: Okta +* Tactic: Credential Access + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Multiple Okta User Authentication Events with Client Address* + + +This 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. + + +*Possible investigation steps:* + +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. +- 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. +- 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. +- Review the `okta.security_context.is_proxy` field to determine if the device is a proxy. + - If the device is a proxy, this may indicate that a user is using a proxy to access multiple accounts for password spraying. +- With the list of `okta.actor.alternate_id` values, review `event.outcome` results to determine if the authentication was successful. + - If the authentication was successful for any user, pivoting to `event.action` values for those users may provide additional context. +- With Okta end users identified, review the `okta.debug_context.debug_data.dt_hash` field. + - Historical analysis should indicate if this device token hash is commonly associated with the user. +- Review the `okta.event_type` field to determine the type of authentication event that occurred. + - If the event type is `user.authentication.sso`, the user may have legitimately started a session via a proxy for security or privacy reasons. + - If the event type is `user.authentication.password`, the user may be using a proxy to access multiple accounts for password spraying. + - If the event type is `user.session.start`, the source may have attempted to establish a session via the Okta authentication API. +- Examine the `okta.outcome.result` field to determine if the authentication was successful. +- Review the past activities of the actor(s) involved in this action by checking their previous actions. +- 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. + - This may help determine the authentication and authorization actions that occurred between the user, Okta and application. + + +*False positive analysis:* + +- A user may have legitimately started a session via a proxy for security or privacy reasons. +- Users may share an endpoint related to work or personal use in which separate Okta accounts are used. + - Architecturally, this shared endpoint may leverage a proxy for security or privacy reasons. + - Shared systems such as Kiosks and conference room computers may be used by multiple users. + - Shared working spaces may have a single endpoint that is used by multiple users. + + +*Response and remediation:* + +- Review the profile of the users involved in this action to determine if proxy usage may be expected. +- If the user is legitimate and the authentication behavior is not suspicious based on device analysis, no action is required. +- If the user is legitimate but the authentication behavior is suspicious, consider resetting passwords for the users involves and enabling multi-factor authentication (MFA). + - If MFA is already enabled, consider resetting MFA for the users. +- If any of the users are not legitimate, consider deactivating the user's account. +- Conduct a review of Okta policies and ensure they are in accordance with security best practices. +- Check with internal IT teams to determine if the accounts involved recently had MFA reset at the request of the user. + - If so, confirm with the user this was a legitimate request. + - If so and this was not a legitimate request, consider deactivating the user's account temporarily. + - Reset passwords and reset MFA for the user. +- If this is a false positive, consider adding the `okta.debug_context.debug_data.dt_hash` field to the `exceptions` list in the rule. + - This will prevent future occurrences of this event for this device from triggering the rule. + - Alternatively adding `okta.client.ip` or a CIDR range to the `exceptions` list can prevent future occurrences of this event from triggering the rule. + - This should be done with caution as it may prevent legitimate alerts from being generated. + + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-okta* +| WHERE + event.dataset == "okta.system" + AND (event.action == "user.session.start" OR event.action RLIKE "user\\.authentication(.*)") + AND okta.outcome.reason == "INVALID_CREDENTIALS" +| STATS + source_auth_count = COUNT_DISTINCT(okta.actor.id) + BY okta.client.ip, okta.actor.alternate_id +| WHERE + source_auth_count > 5 +| SORT + source_auth_count DESC + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Credential Stuffing +** ID: T1110.004 +** Reference URL: https://attack.mitre.org/techniques/T1110/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-multiple-okta-user-authentication-events-with-same-device-token-hash.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-multiple-okta-user-authentication-events-with-same-device-token-hash.asciidoc new file mode 100644 index 0000000000..775e49f67e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-multiple-okta-user-authentication-events-with-same-device-token-hash.asciidoc @@ -0,0 +1,149 @@ +[[prebuilt-rule-8-13-10-multiple-okta-user-authentication-events-with-same-device-token-hash]] +=== Multiple Okta User Authentication Events with Same Device Token Hash + +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. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*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/ + +*Tags*: + +* Use Case: Identity and Access Audit +* Data Source: Okta +* Tactic: Credential Access + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Multiple Okta User Authentication Events with Same Device Token Hash* + + +This 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. + + +*Possible investigation steps:* + +- 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. +- 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. +- 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. +- Review the `okta.security_context.is_proxy` field to determine if the device is a proxy. + - If the device is a proxy, this may indicate that a user is using a proxy to access multiple accounts for password spraying. +- With the list of `okta.actor.alternate_id` values, review `event.outcome` results to determine if the authentication was successful. + - If the authentication was successful for any user, pivoting to `event.action` values for those users may provide additional context. +- With Okta end users identified, review the `okta.debug_context.debug_data.dt_hash` field. + - Historical analysis should indicate if this device token hash is commonly associated with the user. +- Review the `okta.event_type` field to determine the type of authentication event that occurred. + - If the event type is `user.authentication.sso`, the user may have legitimately started a session via a proxy for security or privacy reasons. + - If the event type is `user.authentication.password`, the user may be using a proxy to access multiple accounts for password spraying. +- Examine the `okta.outcome.result` field to determine if the authentication was successful. +- Review the past activities of the actor(s) involved in this action by checking their previous actions. +- 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. + - This may help determine the authentication and authorization actions that occurred between the user, Okta and application. + + +*False positive analysis:* + +- A user may have legitimately started a session via a proxy for security or privacy reasons. +- Users may share an endpoint related to work or personal use in which separate Okta accounts are used. + - Architecturally, this shared endpoint may leverage a proxy for security or privacy reasons. + - Shared systems such as Kiosks and conference room computers may be used by multiple users. + - Shared working spaces may have a single endpoint that is used by multiple users. + + +*Response and remediation:* + +- Review the profile of the users involved in this action to determine if proxy usage may be expected. +- If the user is legitimate and the authentication behavior is not suspicious based on device analysis, no action is required. +- If the user is legitimate but the authentication behavior is suspicious, consider resetting passwords for the users involves and enabling multi-factor authentication (MFA). + - If MFA is already enabled, consider resetting MFA for the users. +- If any of the users are not legitimate, consider deactivating the user's account. +- Conduct a review of Okta policies and ensure they are in accordance with security best practices. +- Check with internal IT teams to determine if the accounts involved recently had MFA reset at the request of the user. + - If so, confirm with the user this was a legitimate request. + - If so and this was not a legitimate request, consider deactivating the user's account temporarily. + - Reset passwords and reset MFA for the user. +- If this is a false positive, consider adding the `okta.debug_context.debug_data.dt_hash` field to the `exceptions` list in the rule. + - This will prevent future occurrences of this event for this device from triggering the rule. + + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-okta* +| WHERE + event.dataset == "okta.system" + AND (event.action RLIKE "user\\.authentication(.*)" OR event.action == "user.session.start") + AND okta.debug_context.debug_data.dt_hash != "-" + AND okta.outcome.reason == "INVALID_CREDENTIALS" +| STATS + target_auth_count = COUNT_DISTINCT(okta.actor.id) + BY okta.debug_context.debug_data.dt_hash, okta.actor.alternate_id +| WHERE + target_auth_count > 20 +| SORT + target_auth_count DESC + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Credential Stuffing +** ID: T1110.004 +** Reference URL: https://attack.mitre.org/techniques/T1110/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-network-traffic-to-rare-destination-country.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-network-traffic-to-rare-destination-country.asciidoc new file mode 100644 index 0000000000..d179a430b1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-network-traffic-to-rare-destination-country.asciidoc @@ -0,0 +1,99 @@ +[[prebuilt-rule-8-13-10-network-traffic-to-rare-destination-country]] +=== Network Traffic to Rare Destination Country + +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. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-30m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html + +*Tags*: + +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning + +*Version*: 104 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Network Packet Capture + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Network Packet Capture Integration Setup* + +The 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 — 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. + + +*The following steps should be executed in order to add the Elastic Agent System integration "network_traffic" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Network Packet Capture” and select the integration to see more details about it. +- Click “Add Network Packet Capture”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “network_traffic” to an existing or a new agent policy, and deploy the agent on your system from which network log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/network_traffic[helper guide]. + diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-ntds-dump-via-wbadmin.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-ntds-dump-via-wbadmin.asciidoc new file mode 100644 index 0000000000..7bd932f541 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-ntds-dump-via-wbadmin.asciidoc @@ -0,0 +1,84 @@ +[[prebuilt-rule-8-13-10-ntds-dump-via-wbadmin]] +=== NTDS Dump via Wbadmin + +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. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-windows.* +* endgame-* +* logs-system.security* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://medium.com/r3d-buck3t/windows-privesc-with-sebackupprivilege-65d2cd1eb960 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Elastic Endgame +* Data Source: Elastic Defend + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + (process.name : "wbadmin.exe" or ?process.pe.original_file_name : "wbadmin.exe") and + process.args : "recovery" and process.command_line : "*ntds.dit*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: Security Account Manager +** ID: T1003.002 +** Reference URL: https://attack.mitre.org/techniques/T1003/002/ +* Sub-technique: +** Name: NTDS +** ID: T1003.003 +** Reference URL: https://attack.mitre.org/techniques/T1003/003/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Direct Volume Access +** ID: T1006 +** Reference URL: https://attack.mitre.org/techniques/T1006/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-okta-user-sessions-started-from-different-geolocations.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-okta-user-sessions-started-from-different-geolocations.asciidoc new file mode 100644 index 0000000000..23f5bb434e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-okta-user-sessions-started-from-different-geolocations.asciidoc @@ -0,0 +1,134 @@ +[[prebuilt-rule-8-13-10-okta-user-sessions-started-from-different-geolocations]] +=== Okta User Sessions Started from Different Geolocations + +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. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 15m + +*Searches indices from*: now-30m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*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/ + +*Tags*: + +* Use Case: Identity and Access Audit +* Data Source: Okta +* Tactic: Initial Access + +*Version*: 101 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + + +*Triage and analysis* + + + +*Investigating Okta User Sessions Started from Different Geolocations* + + +This 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. + + +*Possible investigation steps:* + +- 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. +- 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. +- 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. +- With Okta end users identified, review the `okta.debug_context.debug_data.dt_hash` field. + - Historical analysis should indicate if this device token hash is commonly associated with the user. +- Review the `okta.event_type` field to determine the type of authentication event that occurred. + - If the event type is `user.authentication.sso`, the user may have legitimately started a session via a proxy for security or privacy reasons. + - If the event type is `user.authentication.password`, the user may be using a proxy to access multiple accounts for password spraying. + - If the event type is `user.session.start`, the source may have attempted to establish a session via the Okta authentication API. +- Review the past activities of the actor(s) involved in this action by checking their previous actions. +- 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. + - This may help determine the authentication and authorization actions that occurred between the user, Okta and application. + + +*False positive analysis:* + +- It is very rare that a legitimate user would have multiple sessions started from different geo-located countries in a short time frame. + + +*Response and remediation:* + +- If the user is legitimate and the authentication behavior is not suspicious based on device analysis, no action is required. +- If the user is legitimate but the authentication behavior is suspicious, consider resetting passwords for the users involves and enabling multi-factor authentication (MFA). + - If MFA is already enabled, consider resetting MFA for the users. +- If any of the users are not legitimate, consider deactivating the user's account. +- Conduct a review of Okta policies and ensure they are in accordance with security best practices. +- Check with internal IT teams to determine if the accounts involved recently had MFA reset at the request of the user. + - If so, confirm with the user this was a legitimate request. + - If so and this was not a legitimate request, consider deactivating the user's account temporarily. + - Reset passwords and reset MFA for the user. +- If this is a false positive, consider adding the `okta.debug_context.debug_data.dt_hash` field to the `exceptions` list in the rule. + - This will prevent future occurrences of this event for this device from triggering the rule. + - Alternatively adding `okta.client.ip` or a CIDR range to the `exceptions` list can prevent future occurrences of this event from triggering the rule. + - This should be done with caution as it may prevent legitimate alerts from being generated. + + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-okta* +| WHERE + event.dataset == "okta.system" + AND (event.action RLIKE "user\\.authentication(.*)" OR event.action == "user.session.start") + AND okta.security_context.is_proxy != true and okta.actor.id != "unknown" + AND event.outcome == "success" +| STATS + geo_auth_counts = COUNT_DISTINCT(client.geo.country_name) + BY okta.actor.id, okta.actor.alternate_id +| WHERE + geo_auth_counts >= 2 + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Cloud Accounts +** ID: T1078.004 +** Reference URL: https://attack.mitre.org/techniques/T1078/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-potential-persistence-via-file-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-potential-persistence-via-file-modification.asciidoc new file mode 100644 index 0000000000..b9ae1b5b07 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-potential-persistence-via-file-modification.asciidoc @@ -0,0 +1,197 @@ +[[prebuilt-rule-8-13-10-potential-persistence-via-file-modification]] +=== Potential Persistence via File Modification + +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. + +*Rule type*: eql + +*Rule indices*: + +* logs-fim.event-* +* auditbeat-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Privilege Escalation +* Data Source: File Integrity Monitoring + +*Version*: 2 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from the Elastic File Integrity Monitoring (FIM) integration. + + +*Elastic FIM Integration Setup* + +To configure the Elastic FIM integration, follow these steps: + +1. Install and configure the Elastic Agent on your Linux system. You can refer to the https://www.elastic.co/guide/en/fleet/current/elastic-agent-installation.html[Elastic Agent documentation] for detailed instructions. +2. Once the Elastic Agent is installed, navigate to the Elastic Security app in Kibana. +3. In the Kibana home page, click on "Integrations" in the left sidebar. +4. Search for "File Integrity Monitoring" in the search bar and select the integration. +5. Provide a name and optional description for the integration. +6. Select the appropriate agent policy for your Linux system or create a new one. +7. 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. +8. Save the configuration and the Elastic Agent will start monitoring the specified paths for file modifications. + +For more details on configuring the Elastic FIM integration, you can refer to the https://docs.elastic.co/integrations/fim[Elastic FIM documentation]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and event.dataset == "fim.event" and event.action == "updated" and +file.path : ( + // cron, anacron & at + "/etc/cron.d/*", "/etc/cron.daily/*", "/etc/cron.hourly/*", "/etc/cron.monthly/*", + "/etc/cron.weekly/*", "/etc/crontab", "/var/spool/cron/crontabs/*", "/etc/cron.allow", + "/etc/cron.deny", "/var/spool/anacron/*", "/var/spool/cron/atjobs/*", + + // systemd services & timers + "/etc/systemd/system/*", "/usr/local/lib/systemd/system/*", "/lib/systemd/system/*", + "/usr/lib/systemd/system/*", "/home/*/.config/systemd/user/*", "/home/*/.local/share/systemd/user/*", + "/root/.config/systemd/user/*", "/root/.local/share/systemd/user/*", + + // LD_PRELOAD + "/etc/ld.so.preload", "/etc/ld.so.conf.d/*", "/etc/ld.so.conf", + + // message-of-the-day (MOTD) + "/etc/update-motd.d/*", + + // SSH + "/home/*/.ssh/*", "/root/.ssh/*", "/etc/ssh/*", + + // system-wide shell configurations + "/etc/profile", "/etc/profile.d/*", "/etc/bash.bashrc", "/etc/zsh/*", "/etc/csh.cshrc", + "/etc/csh.login", "/etc/fish/config.fish", "/etc/ksh.kshrc", + + // root and user shell configurations + "/home/*/.profile", "/home/*/.bashrc", "/home/*/.bash_login", "/home/*/.bash_logout", + "/root/.profile", "/root/.bashrc", "/root/.bash_login", "/root/.bash_logout", + "/home/*/.zprofile", "/home/*/.zshrc", "/root/.zprofile", "/root/.zshrc", + "/home/*/.cshrc", "/home/*/.login", "/home/*/.logout", "/root/.cshrc", "/root/.login", "/root/.logout", + "/home/*/.config/fish/config.fish", "/root/.config/fish/config.fish", + "/home/*/.kshrc", "/root/.kshrc", + + // runtime control + "/etc/rc.common", "/etc/rc.local", + + // init daemon + "/etc/init.d/*", + + // passwd/sudoers/shadow + "/etc/passwd", "/etc/shadow", "/etc/sudoers", "/etc/sudoers.d/*", + + // Systemd udevd + "/lib/udev/*", "/etc/udev/rules.d/*", "/usr/lib/udev/rules.d/*", "/run/udev/rules.d/*", + + // XDG/KDE autostart entries + "/home/*/.config/autostart/*", "/root/.config/autostart/*", "/etc/xdg/autostart/*", "/usr/share/autostart/*", + "/home/*/.kde/Autostart/*", "/root/.kde/Autostart/*", + "/home/*/.kde4/Autostart/*", "/root/.kde4/Autostart/*", + "/home/*/.kde/share/autostart/*", "/root/.kde/share/autostart/*", + "/home/*/.kde4/share/autostart/*", "/root/.kde4/share/autostart/*", + "/home/*/.local/share/autostart/*", "/root/.local/share/autostart/*", + "/home/*/.config/autostart-scripts/*", "/root/.config/autostart-scripts/*" +) and not ( + file.path : ( + "/var/spool/cron/crontabs/tmp.*", "/run/udev/rules.d/*rules.*", "/home/*/.ssh/known_hosts.*", "/root/.ssh/known_hosts.*" + ) or + file.extension in ("dpkg-new", "dpkg-remove", "SEQ") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Boot or Logon Initialization Scripts +** ID: T1037 +** Reference URL: https://attack.mitre.org/techniques/T1037/ +* Sub-technique: +** Name: RC Scripts +** ID: T1037.004 +** Reference URL: https://attack.mitre.org/techniques/T1037/004/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Sub-technique: +** Name: Systemd Service +** ID: T1543.002 +** Reference URL: https://attack.mitre.org/techniques/T1543/002/ +* Technique: +** Name: Modify Authentication Process +** ID: T1556 +** Reference URL: https://attack.mitre.org/techniques/T1556/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: Dynamic Linker Hijacking +** ID: T1574.006 +** Reference URL: https://attack.mitre.org/techniques/T1574/006/ +* Technique: +** Name: Create Account +** ID: T1136 +** Reference URL: https://attack.mitre.org/techniques/T1136/ +* Sub-technique: +** Name: Local Account +** ID: T1136.001 +** Reference URL: https://attack.mitre.org/techniques/T1136/001/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Scheduled Task/Job +** ID: T1053 +** Reference URL: https://attack.mitre.org/techniques/T1053/ +* Sub-technique: +** Name: Cron +** ID: T1053.003 +** Reference URL: https://attack.mitre.org/techniques/T1053/003/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Sub-technique: +** Name: Sudo and Sudo Caching +** ID: T1548.003 +** Reference URL: https://attack.mitre.org/techniques/T1548/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-potential-privilege-escalation-via-service-imagepath-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-potential-privilege-escalation-via-service-imagepath-modification.asciidoc new file mode 100644 index 0000000000..d37bc5fc53 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-potential-privilege-escalation-via-service-imagepath-modification.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-13-10-potential-privilege-escalation-via-service-imagepath-modification]] +=== Potential Privilege Escalation via Service ImagePath Modification + +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. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.registry-* +* logs-windows.sysmon_operational-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cube0x0.github.io/Pocing-Beyond-DA/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Privilege Escalation +* Data Source: Elastic Defend +* Data Source: Sysmon + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and process.executable != null and + event.action == "modification" and registry.value == "ImagePath" and + registry.key : ( + "*\\ADWS", "*\\AppHostSvc", "*\\AppReadiness", "*\\AudioEndpointBuilder", "*\\AxInstSV", "*\\camsvc", "*\\CertSvc", + "*\\COMSysApp", "*\\CscService", "*\\defragsvc", "*\\DeviceAssociationService", "*\\DeviceInstall", "*\\DevQueryBroker", + "*\\Dfs", "*\\DFSR", "*\\diagnosticshub.standardcollector.service", "*\\DiagTrack", "*\\DmEnrollmentSvc", "*\\DNS", + "*\\dot3svc", "*\\Eaphost", "*\\GraphicsPerfSvc", "*\\hidserv", "*\\HvHost", "*\\IISADMIN", "*\\IKEEXT", + "*\\InstallService", "*\\iphlpsvc", "*\\IsmServ", "*\\LanmanServer", "*\\MSiSCSI", "*\\NcbService", "*\\Netlogon", + "*\\Netman", "*\\NtFrs", "*\\PlugPlay", "*\\Power", "*\\PrintNotify", "*\\ProfSvc", "*\\PushToInstall", "*\\RSoPProv", + "*\\sacsvr", "*\\SENS", "*\\SensorDataService", "*\\SgrmBroker", "*\\ShellHWDetection", "*\\shpamsvc", "*\\StorSvc", + "*\\svsvc", "*\\swprv", "*\\SysMain", "*\\Themes", "*\\TieringEngineService", "*\\TokenBroker", "*\\TrkWks", + "*\\UALSVC", "*\\UserManager", "*\\vm3dservice", "*\\vmicguestinterface", "*\\vmicheartbeat", "*\\vmickvpexchange", + "*\\vmicrdv", "*\\vmicshutdown", "*\\vmicvmsession", "*\\vmicvss", "*\\vmvss", "*\\VSS", "*\\w3logsvc", "*\\W3SVC", + "*\\WalletService", "*\\WAS", "*\\wercplsupport", "*\\WerSvc", "*\\Winmgmt", "*\\wisvc", "*\\wmiApSrv", + "*\\WPDBusEnum", "*\\WSearch" + ) and + not ( + registry.data.strings : ( + "?:\\Windows\\system32\\*.exe", + "%systemroot%\\system32\\*.exe", + "%windir%\\system32\\*.exe", + "%SystemRoot%\\system32\\svchost.exe -k *", + "%windir%\\system32\\svchost.exe -k *" + ) and + not registry.data.strings : ( + "*\\cmd.exe", + "*\\cscript.exe", + "*\\ieexec.exe", + "*\\iexpress.exe", + "*\\installutil.exe", + "*\\Microsoft.Workflow.Compiler.exe", + "*\\msbuild.exe", + "*\\mshta.exe", + "*\\msiexec.exe", + "*\\msxsl.exe", + "*\\net.exe", + "*\\powershell.exe", + "*\\pwsh.exe", + "*\\reg.exe", + "*\\RegAsm.exe", + "*\\RegSvcs.exe", + "*\\regsvr32.exe", + "*\\rundll32.exe", + "*\\vssadmin.exe", + "*\\wbadmin.exe", + "*\\wmic.exe", + "*\\wscript.exe" + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Sub-technique: +** Name: Windows Service +** ID: T1543.003 +** Reference URL: https://attack.mitre.org/techniques/T1543/003/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: Services Registry Permissions Weakness +** ID: T1574.011 +** Reference URL: https://attack.mitre.org/techniques/T1574/011/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: System Services +** ID: T1569 +** Reference URL: https://attack.mitre.org/techniques/T1569/ +* Sub-technique: +** Name: Service Execution +** ID: T1569.002 +** Reference URL: https://attack.mitre.org/techniques/T1569/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-potential-wpad-spoofing-via-dns-record-creation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-potential-wpad-spoofing-via-dns-record-creation.asciidoc new file mode 100644 index 0000000000..fcc7992c9e --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-potential-wpad-spoofing-via-dns-record-creation.asciidoc @@ -0,0 +1,94 @@ +[[prebuilt-rule-8-13-10-potential-wpad-spoofing-via-dns-record-creation]] +=== Potential WPAD Spoofing via DNS Record Creation + +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. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-system.* +* logs-windows.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.thehacker.recipes/ad/movement/mitm-and-coerced-authentications/wpad-spoofing#through-adidns-spoofing +* https://cube0x0.github.io/Pocing-Beyond-DA/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Active Directory +* Use Case: Active Directory Monitoring + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Setup + + + +*Setup* + + +The 'Audit Directory Service Changes' logging policy must be configured for (Success, Failure). +Steps to implement the logging policy with Advanced Audit Configuration: + +``` +Computer Configuration > +Policies > +Windows Settings > +Security Settings > +Advanced Audit Policies Configuration > +Audit Policies > +DS Access > +Audit Directory Service Changes (Success,Failure) +``` + +The 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. + +``` +Set-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 +``` + + +==== Rule query + + +[source, js] +---------------------------------- +any where host.os.type == "windows" and event.action == "Directory Service Changes" and + event.code == "5137" and winlog.event_data.ObjectDN : "DC=wpad,*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Adversary-in-the-Middle +** ID: T1557 +** Reference URL: https://attack.mitre.org/techniques/T1557/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-rapid7-threat-command-cves-correlation.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-rapid7-threat-command-cves-correlation.asciidoc new file mode 100644 index 0000000000..532a18bba9 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-rapid7-threat-command-cves-correlation.asciidoc @@ -0,0 +1,117 @@ +[[prebuilt-rule-8-13-10-rapid7-threat-command-cves-correlation]] +=== Rapid7 Threat Command CVEs Correlation + +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. + +*Rule type*: threat_match + +*Rule indices*: + +* auditbeat-* +* endgame-* +* filebeat-* +* logs-* +* packetbeat-* +* winlogbeat-* + +*Severity*: critical + +*Risk score*: 99 + +*Runs every*: 30m + +*Searches indices from*: now-35m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 10000 + +*References*: + +* https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-threatintel.html +* https://docs.elastic.co/integrations/ti_rapid7_threat_command + +*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 + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating Rapid7 Threat Command CVEs Correlation* + + +Rapid7 Threat Command CVEs Correlation rule allows matching CVEs from user indices within the vulnerabilities collected from Rapid7 Threat Command integrations. + +The 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. + +If a vulnerability matches a local observation, the following enriched fields will be generated to identify the vulnerability, field, and type matched. + +- `threat.indicator.matched.atomic` - this identifies the atomic vulnerability that matched the local observation +- `threat.indicator.matched.field` - this identifies the vulnerability field that matched the local observation +- `threat.indicator.matched.type` - this identifies the vulnerability type that matched the local observation + +Additional 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. + +- Investigation can be validated and reviewed based on the data that was matched and by viewing the source of that activity. +- 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. +- Consider the user and their role within the company: is this something related to their job or work function? + + +==== Setup + + + + +*Setup* + + +This rule needs threat intelligence indicators to work. +Threat intelligence indicators can be collected using an https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html#agent-ti-integration[Elastic Agent integration], +the https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html#ti-mod-integration[Threat Intel module], +or a https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html#custom-ti-integration[custom integration]. + +More information can be found https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html[here]. + + +*Max Signals* + + +This 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. + +**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. + +To 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. + +**NOTE:** Changing `xpack.alerting.rules.run.alerts.max` is not possible in Serverless projects. + + +==== Rule query + + +[source, js] +---------------------------------- +vulnerability.id : * + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-rare-aws-error-code.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-rare-aws-error-code.asciidoc new file mode 100644 index 0000000000..e872855ee6 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-rare-aws-error-code.asciidoc @@ -0,0 +1,145 @@ +[[prebuilt-rule-8-13-10-rare-aws-error-code]] +=== Rare AWS Error Code + +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. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-2h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Rule Type: ML +* Rule Type: Machine Learning +* Resources: Investigation Guide + +*Version*: 209 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Rare AWS Error Code* + + +CloudTrail 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. + +This 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. + +Detection 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. + + +*Possible investigation steps* + + +- 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. +- Investigate other alerts associated with the user account during the past 48 hours. +- Validate the activity is not related to planned patches, updates, or network administrator activity. +- Examine the request parameters. These may indicate the source of the program or the nature of the task being performed when the error occurred. + - Check whether the error is related to unsuccessful attempts to enumerate or access objects, data, or secrets. +- Considering the source IP address and geolocation of the user who issued the command: + - Do they look normal for the calling user? + - 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? + - 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? +- 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? +- Contact the account owner and confirm whether they are aware of this activity if suspicious. +- 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. + + +*False positive analysis* + + +- 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. +- The adoption of new services or the addition of new functionality to scripts may generate false positives. + + +*Related Rules* + + +- Unusual City For an AWS Command - 809b70d3-e2c3-455e-af1b-2626a5a1a276 +- Unusual Country For an AWS Command - dca28dee-c999-400f-b640-50a081cc0fd1 +- Unusual AWS Command for a User - ac706eae-d5ec-4b14-b4fd-e8ba8086f0e1 +- Spike in AWS Error Messages - 78d3d8d9-b476-451d-a9e0-7a5addd70670 + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- 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. +- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users. +- Consider enabling multi-factor authentication for users. +- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. +- Implement security best practices https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[outlined] by AWS. +- Take the actions needed to return affected systems, data, or services to their normal operational levels. +- Identify the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- 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). + + +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from AWS. + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*AWS Integration Setup* + +The AWS integration allows you to collect logs and metrics from Amazon Web Services (AWS) with Elastic Agent. + + +*The following steps should be executed in order to add the Elastic Agent System integration "aws" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “AWS” and select the integration to see more details about it. +- Click “Add AWS”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “aws” to an existing or a new agent policy, and deploy the agent on your system from which aws log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://www.elastic.co/docs/current/integrations/aws[helper guide]. + diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-rare-user-logon.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-rare-user-logon.asciidoc new file mode 100644 index 0000000000..f7bd91d3dc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-rare-user-logon.asciidoc @@ -0,0 +1,184 @@ +[[prebuilt-rule-8-13-10-rare-user-logon]] +=== Rare User Logon + +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. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-30m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html + +*Tags*: + +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Initial Access +* Resources: Investigation Guide + +*Version*: 105 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Rare User Logon* + + +This rule uses a machine learning job to detect an unusual user name in authentication logs, which could detect new accounts created for persistence. + + +*Possible investigation steps* + + +- Check if the user was newly created and if the company policies were followed. + - Identify the user account that performed the action and whether it should perform this kind of action. +- Investigate other alerts associated with the involved users during the past 48 hours. +- Investigate any abnormal account behavior, such as command executions, file creations or modifications, and network connections. + + +*False positive analysis* + + +- Accounts that are used for specific purposes — and therefore not normally active — may trigger the alert. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- 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. +- 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). + + +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Auditd Manager +- System + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditd Manager Integration Setup* + +The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel. +Auditd 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. + + +*The following steps should be executed in order to add the Elastic Agent System integration "auditd_manager" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Auditd Manager” and select the integration to see more details about it. +- Click “Add Auditd Manager”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “auditd manager” to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/auditd_manager[helper guide]. + + +*Rule Specific Setup Note* + +Auditd Manager subscribes to the kernel and receives events as they occur without any additional configuration. +However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from. +- For this detection rule no additional audit rules are required. + + +*System Integration Setup* + +The System integration allows you to collect system logs and metrics from your servers with Elastic Agent. + + +*The following steps should be executed in order to add the Elastic Agent System integration "system" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “System” and select the integration to see more details about it. +- Click “Add System”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “system” to an existing or a new agent policy, and deploy the agent on your system from which system log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/system[helper guide]. + + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Domain Accounts +** ID: T1078.002 +** Reference URL: https://attack.mitre.org/techniques/T1078/002/ +* Sub-technique: +** Name: Local Accounts +** ID: T1078.003 +** Reference URL: https://attack.mitre.org/techniques/T1078/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-spike-in-aws-error-messages.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-spike-in-aws-error-messages.asciidoc new file mode 100644 index 0000000000..a38cb266b1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-spike-in-aws-error-messages.asciidoc @@ -0,0 +1,143 @@ +[[prebuilt-rule-8-13-10-spike-in-aws-error-messages]] +=== Spike in AWS Error Messages + +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. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-60m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Rule Type: ML +* Rule Type: Machine Learning +* Resources: Investigation Guide + +*Version*: 209 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Spike in AWS Error Messages* + + +CloudTrail 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. + +This 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. + + +*Possible investigation steps* + + +- 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. +- Investigate other alerts associated with the user account during the past 48 hours. +- Validate the activity is not related to planned patches, updates, or network administrator activity. +- Examine the request parameters. These may indicate the source of the program or the nature of the task being performed when the error occurred. + - Check whether the error is related to unsuccessful attempts to enumerate or access objects, data, or secrets. +- Considering the source IP address and geolocation of the user who issued the command: + - Do they look normal for the calling user? + - 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? + - 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? +- 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? +- Contact the account owner and confirm whether they are aware of this activity if suspicious. +- 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. + + +*False positive analysis* + + +- 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. +- The adoption of new services or the addition of new functionality to scripts may generate false positives. + + +*Related Rules* + + +- Unusual City For an AWS Command - 809b70d3-e2c3-455e-af1b-2626a5a1a276 +- Unusual Country For an AWS Command - dca28dee-c999-400f-b640-50a081cc0fd1 +- Unusual AWS Command for a User - ac706eae-d5ec-4b14-b4fd-e8ba8086f0e1 +- Rare AWS Error Code - 19de8096-e2b0-4bd8-80c9-34a820813fff + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- 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. +- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users. +- Consider enabling multi-factor authentication for users. +- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. +- Implement security best practices https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[outlined] by AWS. +- Take the actions needed to return affected systems, data, or services to their normal operational levels. +- Identify the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- 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). + + +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from AWS. + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*AWS Integration Setup* + +The AWS integration allows you to collect logs and metrics from Amazon Web Services (AWS) with Elastic Agent. + + +*The following steps should be executed in order to add the Elastic Agent System integration "aws" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “AWS” and select the integration to see more details about it. +- Click “Add AWS”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “aws” to an existing or a new agent policy, and deploy the agent on your system from which aws log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://www.elastic.co/docs/current/integrations/aws[helper guide]. + diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-spike-in-failed-logon-events.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-spike-in-failed-logon-events.asciidoc new file mode 100644 index 0000000000..d72c835ac3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-spike-in-failed-logon-events.asciidoc @@ -0,0 +1,184 @@ +[[prebuilt-rule-8-13-10-spike-in-failed-logon-events]] +=== Spike in Failed Logon Events + +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. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-30m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html + +*Tags*: + +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Credential Access +* Resources: Investigation Guide + +*Version*: 105 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Spike in Failed Logon Events* + + +This 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. + + +*Possible investigation steps* + + +- Identify the users involved and if the activity targets a specific user or a set of users. +- Check if the authentication comes from different sources. +- Investigate if the host where the failed authentication events occur is exposed to the internet. + - 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. + - 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. +- Investigate other alerts associated with the involved users and hosts during the past 48 hours. +- Check whether the involved credentials are used in automation or scheduled tasks. +- If this activity is suspicious, contact the account owner and confirm whether they are aware of it. +- Investigate whether there are successful authentication events from the involved sources. This could indicate a successful brute force or password spraying attack. + + +*False positive analysis* + + +- If the account is used in automation tasks, it is possible that they are using expired credentials, causing a spike in authentication failures. +- Authentication failures can be related to permission issues. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- 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. +- Assess whether the asset should be exposed to the internet, and take action to reduce your attack surface. + - If the asset needs to be exposed to the internet, restrict access to remote login services to specific IPs. +- 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). + + +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Auditd Manager +- System + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditd Manager Integration Setup* + +The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel. +Auditd 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. + + +*The following steps should be executed in order to add the Elastic Agent System integration "auditd_manager" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Auditd Manager” and select the integration to see more details about it. +- Click “Add Auditd Manager”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “auditd manager” to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/auditd_manager[helper guide]. + + +*Rule Specific Setup Note* + +Auditd Manager subscribes to the kernel and receives events as they occur without any additional configuration. +However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from. +- For this detection rule no additional audit rules are required. + + +*System Integration Setup* + +The System integration allows you to collect system logs and metrics from your servers with Elastic Agent. + + +*The following steps should be executed in order to add the Elastic Agent System integration "system" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “System” and select the integration to see more details about it. +- Click “Add System”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “system” to an existing or a new agent policy, and deploy the agent on your system from which system log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/system[helper guide]. + + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-spike-in-firewall-denies.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-spike-in-firewall-denies.asciidoc new file mode 100644 index 0000000000..a0c6daadb4 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-spike-in-firewall-denies.asciidoc @@ -0,0 +1,99 @@ +[[prebuilt-rule-8-13-10-spike-in-firewall-denies]] +=== Spike in Firewall Denies + +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. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-30m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html + +*Tags*: + +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning + +*Version*: 104 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Network Packet Capture + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Network Packet Capture Integration Setup* + +The 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 — 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. + + +*The following steps should be executed in order to add the Elastic Agent System integration "network_traffic" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Network Packet Capture” and select the integration to see more details about it. +- Click “Add Network Packet Capture”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “network_traffic” to an existing or a new agent policy, and deploy the agent on your system from which network log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/network_traffic[helper guide]. + diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-spike-in-logon-events.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-spike-in-logon-events.asciidoc new file mode 100644 index 0000000000..0ea335952b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-spike-in-logon-events.asciidoc @@ -0,0 +1,138 @@ +[[prebuilt-rule-8-13-10-spike-in-logon-events]] +=== Spike in Logon Events + +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. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-30m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html + +*Tags*: + +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Credential Access + +*Version*: 104 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Auditd Manager +- System + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditd Manager Integration Setup* + +The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel. +Auditd 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. + + +*The following steps should be executed in order to add the Elastic Agent System integration "auditd_manager" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Auditd Manager” and select the integration to see more details about it. +- Click “Add Auditd Manager”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “auditd manager” to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/auditd_manager[helper guide]. + + +*Rule Specific Setup Note* + +Auditd Manager subscribes to the kernel and receives events as they occur without any additional configuration. +However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from. +- For this detection rule no additional audit rules are required. + + +*System Integration Setup* + +The System integration allows you to collect system logs and metrics from your servers with Elastic Agent. + + +*The following steps should be executed in order to add the Elastic Agent System integration "system" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “System” and select the integration to see more details about it. +- Click “Add System”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “system” to an existing or a new agent policy, and deploy the agent on your system from which system log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/system[helper guide]. + + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-spike-in-network-traffic-to-a-country.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-spike-in-network-traffic-to-a-country.asciidoc new file mode 100644 index 0000000000..409d7f0381 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-spike-in-network-traffic-to-a-country.asciidoc @@ -0,0 +1,150 @@ +[[prebuilt-rule-8-13-10-spike-in-network-traffic-to-a-country]] +=== Spike in Network Traffic To a Country + +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. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-30m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html + +*Tags*: + +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning + +*Version*: 105 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Spike in Network Traffic To a Country* + + +Monitoring 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. + +This 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. + + +*Possible investigation steps* + + +- Identify the specifics of the involved assets, such as role, criticality, and associated users. +- Investigate other alerts associated with the involved assets during the past 48 hours. +- Examine the data available and determine the exact users and processes involved in those connections. +- 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. +- Consider the time of day. If the user is a human (not a program or script), did the activity occurs during working hours? +- If this activity is suspicious, contact the account owner and confirm whether they are aware of it. + + +*False positive analysis* + + +- 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 — preferably with a combination of user and source conditions. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved hosts to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. + - Remove and block malicious artifacts identified during triage. +- Consider implementing temporary network border rules to block or alert connections to the target country, if relevant. +- 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. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- 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). + + +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Network Packet Capture + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Network Packet Capture Integration Setup* + +The 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 — 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. + + +*The following steps should be executed in order to add the Elastic Agent System integration "network_traffic" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Network Packet Capture” and select the integration to see more details about it. +- Click “Add Network Packet Capture”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “network_traffic” to an existing or a new agent policy, and deploy the agent on your system from which network log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/network_traffic[helper guide]. + diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-spike-in-network-traffic.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-spike-in-network-traffic.asciidoc new file mode 100644 index 0000000000..e5e20698b8 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-spike-in-network-traffic.asciidoc @@ -0,0 +1,99 @@ +[[prebuilt-rule-8-13-10-spike-in-network-traffic]] +=== Spike in Network Traffic + +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. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-30m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html + +*Tags*: + +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning + +*Version*: 104 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Network Packet Capture + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Network Packet Capture Integration Setup* + +The 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 — 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. + + +*The following steps should be executed in order to add the Elastic Agent System integration "network_traffic" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Network Packet Capture” and select the integration to see more details about it. +- Click “Add Network Packet Capture”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “network_traffic” to an existing or a new agent policy, and deploy the agent on your system from which network log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/network_traffic[helper guide]. + diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-spike-in-successful-logon-events-from-a-source-ip.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-spike-in-successful-logon-events-from-a-source-ip.asciidoc new file mode 100644 index 0000000000..d7eee643fb --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-spike-in-successful-logon-events-from-a-source-ip.asciidoc @@ -0,0 +1,195 @@ +[[prebuilt-rule-8-13-10-spike-in-successful-logon-events-from-a-source-ip]] +=== Spike in Successful Logon Events from a Source IP + +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. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-30m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html + +*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 + +*Version*: 105 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Spike in Successful Logon Events from a Source IP* + + +This 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. + + +*Possible investigation steps* + + +- Identify the specifics of the involved assets, such as role, criticality, and associated users. +- Check if the authentication comes from different sources. +- Use the historical data available to determine if the same behavior happened in the past. +- Investigate other alerts associated with the involved users during the past 48 hours. +- Check whether the involved credentials are used in automation or scheduled tasks. +- If this activity is suspicious, contact the account owner and confirm whether they are aware of it. + + +*False positive analysis* + + +- 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 — preferably with a combination of user and source conditions. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- 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. +- 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). + + +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Auditd Manager +- System + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditd Manager Integration Setup* + +The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel. +Auditd 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. + + +*The following steps should be executed in order to add the Elastic Agent System integration "auditd_manager" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Auditd Manager” and select the integration to see more details about it. +- Click “Add Auditd Manager”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “auditd manager” to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/auditd_manager[helper guide]. + + +*Rule Specific Setup Note* + +Auditd Manager subscribes to the kernel and receives events as they occur without any additional configuration. +However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from. +- For this detection rule no additional audit rules are required. + + +*System Integration Setup* + +The System integration allows you to collect system logs and metrics from your servers with Elastic Agent. + + +*The following steps should be executed in order to add the Elastic Agent System integration "system" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “System” and select the integration to see more details about it. +- Click “Add System”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “system” to an existing or a new agent policy, and deploy the agent on your system from which system log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/system[helper guide]. + + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Domain Accounts +** ID: T1078.002 +** Reference URL: https://attack.mitre.org/techniques/T1078/002/ +* Sub-technique: +** Name: Local Accounts +** ID: T1078.003 +** Reference URL: https://attack.mitre.org/techniques/T1078/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-suspicious-powershell-script.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-suspicious-powershell-script.asciidoc new file mode 100644 index 0000000000..580e9f46e3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-suspicious-powershell-script.asciidoc @@ -0,0 +1,118 @@ +[[prebuilt-rule-8-13-10-suspicious-powershell-script]] +=== Suspicious Powershell Script + +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. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-45m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*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 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Execution + +*Version*: 105 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Windows + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Windows Integration Setup* + +The Windows integration allows you to monitor the Windows OS, services, applications, and more. + + +*The following steps should be executed in order to add the Elastic Agent System integration "windows" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Windows” and select the integration to see more details about it. +- Click “Add Windows”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “windows” to an existing or a new agent policy, and deploy the agent on your system from which windows log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/windows[helper guide]. + + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: Command and Scripting Interpreter +** ID: T1059 +** Reference URL: https://attack.mitre.org/techniques/T1059/ +* Sub-technique: +** Name: PowerShell +** ID: T1059.001 +** Reference URL: https://attack.mitre.org/techniques/T1059/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-threat-intel-hash-indicator-match.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-threat-intel-hash-indicator-match.asciidoc new file mode 100644 index 0000000000..382d6acefc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-threat-intel-hash-indicator-match.asciidoc @@ -0,0 +1,137 @@ +[[prebuilt-rule-8-13-10-threat-intel-hash-indicator-match]] +=== Threat Intel Hash Indicator Match + +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. + +*Rule type*: threat_match + +*Rule indices*: + +* auditbeat-* +* endgame-* +* filebeat-* +* logs-* +* winlogbeat-* + +*Severity*: critical + +*Risk score*: 99 + +*Runs every*: 1h + +*Searches indices from*: now-65m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*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 + +*Tags*: + +* OS: Windows +* Data Source: Elastic Endgame +* Rule Type: Threat Match + +*Version*: 8 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating Threat Intel Hash Indicator Match* + + +Threat 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. + +Matches 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. + +This 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. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Gain context about the field that matched the local observation. This information can be found in the `threat.indicator.matched.field` field. +- Investigate the hash , which can be found in the `threat.indicator.matched.atomic` field: + - Search for the existence and reputation of the hash in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. + - Scope other potentially compromised hosts in your environment by mapping hosts with file operations involving the same hash. +- Identify the process that created the file. + - 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. + - 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. +- Retrieve the involved file and examine the host for derived artifacts that indicate suspicious activities: + - Analyze the process executable using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{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"}} + - !{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"}} +- Using the data collected through the analysis, scope users targeted and other machines infected in the environment. + + +*False Positive Analysis* + + +- 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. + + +*Response and Remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- 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). + + +==== Setup + + + +*Setup* + + +This rule needs threat intelligence indicators to work. +Threat intelligence indicators can be collected using an https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html#agent-ti-integration[Elastic Agent integration], +the https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html#ti-mod-integration[Threat Intel module], +or a https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html#custom-ti-integration[custom integration]. + +More information can be found https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html[here]. + + +==== Rule query + + +[source, js] +---------------------------------- +file.hash.*:* or process.hash.*:* or dll.hash.*:* + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-threat-intel-ip-address-indicator-match.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-threat-intel-ip-address-indicator-match.asciidoc new file mode 100644 index 0000000000..903871b12f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-threat-intel-ip-address-indicator-match.asciidoc @@ -0,0 +1,139 @@ +[[prebuilt-rule-8-13-10-threat-intel-ip-address-indicator-match]] +=== Threat Intel IP Address Indicator Match + +This rule is triggered when an IP address indicator from the Threat Intel Filebeat module or integrations has a match against a network event. + +*Rule type*: threat_match + +*Rule indices*: + +* auditbeat-* +* endgame-* +* filebeat-* +* logs-* +* packetbeat-* +* winlogbeat-* + +*Severity*: critical + +*Risk score*: 99 + +*Runs every*: 1h + +*Searches indices from*: now-65m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*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 + +*Tags*: + +* OS: Windows +* Data Source: Elastic Endgame +* Rule Type: Threat Match + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating Threat Intel IP Address Indicator Match* + + +Threat 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. + +Matches 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. + +This rule is triggered when an IP address indicator from the Threat Intel Filebeat module or a threat intelligence integration matches against a network event. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- 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. +- Investigate the IP address, which can be found in the `threat.indicator.matched.atomic` field: + - Check the reputation of the IP address in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. + - Execute a reverse DNS lookup to retrieve hostnames associated with the given IP address. +- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts. +- 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. +- Retrieve the involved process executable and examine the host for derived artifacts that indicate suspicious activities: + - Analyze the process executable using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{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"}} + - !{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"}} +- Using the data collected through the analysis, scope users targeted and other machines infected in the environment. + + +*False Positive Analysis* + + +- 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. +- False positives might occur after large and publicly written campaigns if curious employees interact with attacker infrastructure. +- 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. + + +*Response and Remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- 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). + + +==== Setup + + + +*Setup* + + +This rule needs threat intelligence indicators to work. +Threat intelligence indicators can be collected using an https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html#agent-ti-integration[Elastic Agent integration], +the https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html#ti-mod-integration[Threat Intel module], +or a https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html#custom-ti-integration[custom integration]. + +More information can be found https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html[here]. + + +==== Rule query + + +[source, js] +---------------------------------- +source.ip:* or destination.ip:* + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-threat-intel-url-indicator-match.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-threat-intel-url-indicator-match.asciidoc new file mode 100644 index 0000000000..0d862792a3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-threat-intel-url-indicator-match.asciidoc @@ -0,0 +1,142 @@ +[[prebuilt-rule-8-13-10-threat-intel-url-indicator-match]] +=== Threat Intel URL Indicator Match + +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. + +*Rule type*: threat_match + +*Rule indices*: + +* auditbeat-* +* endgame-* +* filebeat-* +* logs-* +* packetbeat-* +* winlogbeat-* + +*Severity*: critical + +*Risk score*: 99 + +*Runs every*: 1h + +*Searches indices from*: now-65m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*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 + +*Tags*: + +* OS: Windows +* Data Source: Elastic Endgame +* Rule Type: Threat Match + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating Threat Intel URL Indicator Match* + + +Threat 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. + +Matches 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. + +This 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. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- Investigate the URL, which can be found in the `threat.indicator.matched.atomic` field: + - Identify the type of malicious activity related to the URL (phishing, malware, etc.). + - Check the reputation of the IP address in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc. + - Execute a WHOIS lookup to retrieve information about the domain registration and contacts to report abuse. + - If dealing with a phishing incident: + - Contact the user to gain more information around the delivery method, information sent, etc. + - 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. + - Investigate the phishing page to identify which information may have been sent to the attacker by the user. +- 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. +- Retrieve the involved process executable and examine the host for derived artifacts that indicate suspicious activities: + - Analyze the process executable using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{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"}} + - !{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"}} +- Using the data collected through the analysis, scope users targeted and other machines infected in the environment. + + +*False Positive Analysis* + + +- False positives might occur after large and publicly written campaigns if curious employees interact with attacker infrastructure. +- 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. + + +*Response and Remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Consider reporting the address for abuse using the provided contact information. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- 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). + + +==== Setup + + + +*Setup* + + +This rule needs threat intelligence indicators to work. +Threat intelligence indicators can be collected using an https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html#agent-ti-integration[Elastic Agent integration], +the https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html#ti-mod-integration[Threat Intel module], +or a https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html#custom-ti-integration[custom integration]. + +More information can be found https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html[here]. + + +==== Rule query + + +[source, js] +---------------------------------- +url.full:* + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-threat-intel-windows-registry-indicator-match.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-threat-intel-windows-registry-indicator-match.asciidoc new file mode 100644 index 0000000000..17b0dad795 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-threat-intel-windows-registry-indicator-match.asciidoc @@ -0,0 +1,132 @@ +[[prebuilt-rule-8-13-10-threat-intel-windows-registry-indicator-match]] +=== Threat Intel Windows Registry Indicator Match + +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. + +*Rule type*: threat_match + +*Rule indices*: + +* auditbeat-* +* endgame-* +* filebeat-* +* logs-* +* winlogbeat-* + +*Severity*: critical + +*Risk score*: 99 + +*Runs every*: 1h + +*Searches indices from*: now-65m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*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 + +*Tags*: + +* OS: Windows +* Data Source: Elastic Endgame +* Rule Type: Threat Match + +*Version*: 7 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating Threat Intel Windows Registry Indicator Match* + + +Threat 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. + +Matches 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. + +This 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. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- 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. +- 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. +- Retrieve the involved process executable and examine the host for derived artifacts that indicate suspicious activities: + - Analyze the process executable using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{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"}} + - !{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"}} +- Using the data collected through the analysis, scope users targeted and other machines infected in the environment. + + +*False Positive Analysis* + + +- 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. + + +*Response and Remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved host to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- 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). + + +==== Setup + + + +*Setup* + + +This rule needs threat intelligence indicators to work. +Threat intelligence indicators can be collected using an https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html#agent-ti-integration[Elastic Agent integration], +the https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html#ti-mod-integration[Threat Intel module], +or a https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html#custom-ti-integration[custom integration]. + +More information can be found https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html[here]. + + +==== Rule query + + +[source, js] +---------------------------------- +registry.path:* + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unsigned-dll-loaded-by-dns-service.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unsigned-dll-loaded-by-dns-service.asciidoc new file mode 100644 index 0000000000..520bb780b1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unsigned-dll-loaded-by-dns-service.asciidoc @@ -0,0 +1,69 @@ +[[prebuilt-rule-8-13-10-unsigned-dll-loaded-by-dns-service]] +=== Unsigned DLL loaded by DNS Service + +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. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.library-* +* logs-windows.sysmon_operational-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cube0x0.github.io/Pocing-Beyond-DA/ +* https://adsecurity.org/?p=4064 +* https://github.com/gtworek/PSBits/tree/master/ServerLevelPluginDll + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Elastic Defend +* Data Source: Sysmon + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Rule query + + +[source, js] +---------------------------------- +any where host.os.type == "windows" and event.category : ("library", "process") and + event.type : ("start", "change") and event.action : ("load", "Image loaded*") and + process.executable : "?:\\windows\\system32\\dns.exe" and + not ?dll.code_signature.trusted == true and + not file.code_signature.status == "Valid" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Exploitation for Privilege Escalation +** ID: T1068 +** Reference URL: https://attack.mitre.org/techniques/T1068/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-aws-command-for-a-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-aws-command-for-a-user.asciidoc new file mode 100644 index 0000000000..412f056b46 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-aws-command-for-a-user.asciidoc @@ -0,0 +1,145 @@ +[[prebuilt-rule-8-13-10-unusual-aws-command-for-a-user]] +=== Unusual AWS Command for a User + +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. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-2h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Rule Type: ML +* Rule Type: Machine Learning +* Resources: Investigation Guide + +*Version*: 209 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Unusual AWS Command for a User* + + +CloudTrail 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. + +This 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. + +Detection alerts from this rule indicate an AWS API command or method call that is rare and unusual for the calling IAM user. + + +*Possible investigation steps* + + +- Identify the user account involved and the action performed. Verify whether it should perform this kind of action. + - 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. + - The user agent details in the `user_agent.original` field may also indicate what kind of a client made the request. +- Investigate other alerts associated with the user account during the past 48 hours. +- Validate the activity is not related to planned patches, updates, or network administrator activity. +- Examine the request parameters. These might indicate the source of the program or the nature of its tasks. +- Considering the source IP address and geolocation of the user who issued the command: + - Do they look normal for the calling user? + - 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? + - 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? +- 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? +- Contact the account owner and confirm whether they are aware of this activity if suspicious. +- 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. + + +*False positive analysis* + + +- 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. + + +*Related Rules* + + +- Unusual City For an AWS Command - 809b70d3-e2c3-455e-af1b-2626a5a1a276 +- Unusual Country For an AWS Command - dca28dee-c999-400f-b640-50a081cc0fd1 +- Rare AWS Error Code - 19de8096-e2b0-4bd8-80c9-34a820813fff +- Spike in AWS Error Messages - 78d3d8d9-b476-451d-a9e0-7a5addd70670 + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- 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. +- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users. +- Consider enabling multi-factor authentication for users. +- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. +- Implement security best practices https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[outlined] by AWS. +- Take the actions needed to return affected systems, data, or services to their normal operational levels. +- Identify the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- 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). + + +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from AWS. + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*AWS Integration Setup* + +The AWS integration allows you to collect logs and metrics from Amazon Web Services (AWS) with Elastic Agent. + + +*The following steps should be executed in order to add the Elastic Agent System integration "aws" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “AWS” and select the integration to see more details about it. +- Click “Add AWS”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “aws” to an existing or a new agent policy, and deploy the agent on your system from which aws log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://www.elastic.co/docs/current/integrations/aws[helper guide]. + diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-city-for-an-aws-command.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-city-for-an-aws-command.asciidoc new file mode 100644 index 0000000000..37ac8572fe --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-city-for-an-aws-command.asciidoc @@ -0,0 +1,146 @@ +[[prebuilt-rule-8-13-10-unusual-city-for-an-aws-command]] +=== Unusual City For an AWS Command + +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). + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-2h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Rule Type: ML +* Rule Type: Machine Learning +* Resources: Investigation Guide + +*Version*: 209 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Unusual City For an AWS Command* + + +CloudTrail 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. + +This 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). + +Detection 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. + + +*Possible investigation steps* + + +- Identify the user account involved and the action performed. Verify whether it should perform this kind of action. + - 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. + - The user agent details in the `user_agent.original` field may also indicate what kind of a client made the request. +- Investigate other alerts associated with the user account during the past 48 hours. +- Validate the activity is not related to planned patches, updates, or network administrator activity. +- Examine the request parameters. These might indicate the source of the program or the nature of its tasks. +- Considering the source IP address and geolocation of the user who issued the command: + - Do they look normal for the calling user? + - 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? + - 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? +- 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? +- Contact the account owner and confirm whether they are aware of this activity if suspicious. +- 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. + + +*False positive analysis* + + +- False positives can occur if activity is coming from new employees based in a city with no previous history in AWS. +- 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. + + +*Related Rules* + + +- Unusual Country For an AWS Command - dca28dee-c999-400f-b640-50a081cc0fd1 +- Unusual AWS Command for a User - ac706eae-d5ec-4b14-b4fd-e8ba8086f0e1 +- Rare AWS Error Code - 19de8096-e2b0-4bd8-80c9-34a820813fff +- Spike in AWS Error Messages - 78d3d8d9-b476-451d-a9e0-7a5addd70670 + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- 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. +- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users. +- Consider enabling multi-factor authentication for users. +- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. +- Implement security best practices https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[outlined] by AWS. +- Take the actions needed to return affected systems, data, or services to their normal operational levels. +- Identify the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- 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). + + +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from AWS. + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*AWS Integration Setup* + +The AWS integration allows you to collect logs and metrics from Amazon Web Services (AWS) with Elastic Agent. + + +*The following steps should be executed in order to add the Elastic Agent System integration "aws" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “AWS” and select the integration to see more details about it. +- Click “Add AWS”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “aws” to an existing or a new agent policy, and deploy the agent on your system from which aws log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://www.elastic.co/docs/current/integrations/aws[helper guide]. + diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-country-for-an-aws-command.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-country-for-an-aws-command.asciidoc new file mode 100644 index 0000000000..4a01d28add --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-country-for-an-aws-command.asciidoc @@ -0,0 +1,146 @@ +[[prebuilt-rule-8-13-10-unusual-country-for-an-aws-command]] +=== Unusual Country For an AWS Command + +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). + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-2h ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html + +*Tags*: + +* Domain: Cloud +* Data Source: AWS +* Data Source: Amazon Web Services +* Rule Type: ML +* Rule Type: Machine Learning +* Resources: Investigation Guide + +*Version*: 209 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Unusual Country For an AWS Command* + + +CloudTrail 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. + +This 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). + +Detection 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. + + +*Possible investigation steps* + + +- Identify the user account involved and the action performed. Verify whether it should perform this kind of action. + - 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. + - The user agent details in the `user_agent.original` field may also indicate what kind of a client made the request. +- Investigate other alerts associated with the user account during the past 48 hours. +- Validate the activity is not related to planned patches, updates, or network administrator activity. +- Examine the request parameters. These might indicate the source of the program or the nature of its tasks. +- Considering the source IP address and geolocation of the user who issued the command: + - Do they look normal for the calling user? + - 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? + - 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? +- 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? +- Contact the account owner and confirm whether they are aware of this activity if suspicious. +- 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. + + +*False Positive Analysis* + + +- False positives can occur if activity is coming from new employees based in a country with no previous history in AWS. +- 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. + + +*Related Rules* + + +- Unusual City For an AWS Command - 809b70d3-e2c3-455e-af1b-2626a5a1a276 +- Unusual AWS Command for a User - ac706eae-d5ec-4b14-b4fd-e8ba8086f0e1 +- Rare AWS Error Code - 19de8096-e2b0-4bd8-80c9-34a820813fff +- Spike in AWS Error Messages - 78d3d8d9-b476-451d-a9e0-7a5addd70670 + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- 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. +- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users. +- Consider enabling multi-factor authentication for users. +- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. +- Implement security best practices https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[outlined] by AWS. +- Take the actions needed to return affected systems, data, or services to their normal operational levels. +- Identify the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- 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). + + +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from AWS. + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*AWS Integration Setup* + +The AWS integration allows you to collect logs and metrics from Amazon Web Services (AWS) with Elastic Agent. + + +*The following steps should be executed in order to add the Elastic Agent System integration "aws" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “AWS” and select the integration to see more details about it. +- Click “Add AWS”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “aws” to an existing or a new agent policy, and deploy the agent on your system from which aws log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://www.elastic.co/docs/current/integrations/aws[helper guide]. + diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-dns-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-dns-activity.asciidoc new file mode 100644 index 0000000000..1df7e3330c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-dns-activity.asciidoc @@ -0,0 +1,115 @@ +[[prebuilt-rule-8-13-10-unusual-dns-activity]] +=== Unusual DNS Activity + +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. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-45m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html + +*Tags*: + +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Command and Control + +*Version*: 104 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Network Packet Capture + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Network Packet Capture Integration Setup* + +The 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 — 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. + + +*The following steps should be executed in order to add the Elastic Agent System integration "network_traffic" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Network Packet Capture” and select the integration to see more details about it. +- Click “Add Network Packet Capture”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “network_traffic” to an existing or a new agent policy, and deploy the agent on your system from which network log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/network_traffic[helper guide]. + + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Sub-technique: +** Name: DNS +** ID: T1071.004 +** Reference URL: https://attack.mitre.org/techniques/T1071/004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-hour-for-a-user-to-logon.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-hour-for-a-user-to-logon.asciidoc new file mode 100644 index 0000000000..a3897964a0 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-hour-for-a-user-to-logon.asciidoc @@ -0,0 +1,176 @@ +[[prebuilt-rule-8-13-10-unusual-hour-for-a-user-to-logon]] +=== Unusual Hour for a User to Logon + +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. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-30m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html + +*Tags*: + +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Initial Access +* Resources: Investigation Guide + +*Version*: 105 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Unusual Hour for a User to Logon* + + +This 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. + + +*Possible investigation steps* + + +- Identify the user account that performed the action and whether it should perform this kind of action. +- Contact the account owner and confirm whether they are aware of this activity. +- Investigate any abnormal account behavior, such as command executions, file creations or modifications, network connections, data access, and logon events. +- Investigate other alerts associated with the involved users during the past 48 hours. + + +*False positive analysis* + + +- 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. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- 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. +- 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). + + +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Auditd Manager +- System + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditd Manager Integration Setup* + +The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel. +Auditd 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. + + +*The following steps should be executed in order to add the Elastic Agent System integration "auditd_manager" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Auditd Manager” and select the integration to see more details about it. +- Click “Add Auditd Manager”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “auditd manager” to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/auditd_manager[helper guide]. + + +*Rule Specific Setup Note* + +Auditd Manager subscribes to the kernel and receives events as they occur without any additional configuration. +However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from. +- For this detection rule no additional audit rules are required. + + +*System Integration Setup* + +The System integration allows you to collect system logs and metrics from your servers with Elastic Agent. + + +*The following steps should be executed in order to add the Elastic Agent System integration "system" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “System” and select the integration to see more details about it. +- Click “Add System”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “system” to an existing or a new agent policy, and deploy the agent on your system from which system log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/system[helper guide]. + + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-linux-network-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-linux-network-activity.asciidoc new file mode 100644 index 0000000000..ff248fc3ed --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-linux-network-activity.asciidoc @@ -0,0 +1,126 @@ +[[prebuilt-rule-8-13-10-unusual-linux-network-activity]] +=== Unusual Linux Network Activity + +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. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-45m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning + +*Version*: 104 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Unusual Network Activity* + +Detection 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: +- Consider the IP addresses and ports. Are these used by normal but infrequent network workflows? Are they expected or unexpected? +- 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. +- 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? +- 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. +- 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. + +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Auditd Manager + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditd Manager Integration Setup* + +The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel. +Auditd 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. + + +*The following steps should be executed in order to add the Elastic Agent System integration "auditd_manager" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Auditd Manager” and select the integration to see more details about it. +- Click “Add Auditd Manager”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “auditd manager” to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/auditd_manager[helper guide]. + + +*Rule Specific Setup Note* + +Auditd Manager subscribes to the kernel and receives events as they occur without any additional configuration. +However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from. +- For this detection rule no additional audit rules are required. + diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-linux-network-configuration-discovery.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-linux-network-configuration-discovery.asciidoc new file mode 100644 index 0000000000..52d9c1d7c1 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-linux-network-configuration-discovery.asciidoc @@ -0,0 +1,119 @@ +[[prebuilt-rule-8-13-10-unusual-linux-network-configuration-discovery]] +=== Unusual Linux Network Configuration Discovery + +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. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-45m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Discovery + +*Version*: 105 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Auditd Manager + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditd Manager Integration Setup* + +The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel. +Auditd 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. + + +*The following steps should be executed in order to add the Elastic Agent System integration "auditd_manager" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Auditd Manager” and select the integration to see more details about it. +- Click “Add Auditd Manager”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “auditd manager” to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/auditd_manager[helper guide]. + + +*Rule Specific Setup Note* + +Auditd Manager subscribes to the kernel and receives events as they occur without any additional configuration. +However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from. +- For this detection rule no additional audit rules are required. + + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Network Configuration Discovery +** ID: T1016 +** Reference URL: https://attack.mitre.org/techniques/T1016/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-linux-network-connection-discovery.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-linux-network-connection-discovery.asciidoc new file mode 100644 index 0000000000..1a30665c04 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-linux-network-connection-discovery.asciidoc @@ -0,0 +1,119 @@ +[[prebuilt-rule-8-13-10-unusual-linux-network-connection-discovery]] +=== Unusual Linux Network Connection Discovery + +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. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-45m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Discovery + +*Version*: 104 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Auditd Manager + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditd Manager Integration Setup* + +The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel. +Auditd 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. + + +*The following steps should be executed in order to add the Elastic Agent System integration "auditd_manager" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Auditd Manager” and select the integration to see more details about it. +- Click “Add Auditd Manager”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “auditd manager” to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/auditd_manager[helper guide]. + + +*Rule Specific Setup Note* + +Auditd Manager subscribes to the kernel and receives events as they occur without any additional configuration. +However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from. +- For this detection rule no additional audit rules are required. + + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Network Connections Discovery +** ID: T1049 +** Reference URL: https://attack.mitre.org/techniques/T1049/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-linux-network-port-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-linux-network-port-activity.asciidoc new file mode 100644 index 0000000000..3ec6bef1f7 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-linux-network-port-activity.asciidoc @@ -0,0 +1,109 @@ +[[prebuilt-rule-8-13-10-unusual-linux-network-port-activity]] +=== Unusual Linux Network Port Activity + +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. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-45m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning + +*Version*: 104 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Auditd Manager + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditd Manager Integration Setup* + +The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel. +Auditd 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. + + +*The following steps should be executed in order to add the Elastic Agent System integration "auditd_manager" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Auditd Manager” and select the integration to see more details about it. +- Click “Add Auditd Manager”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “auditd manager” to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/auditd_manager[helper guide]. + + +*Rule Specific Setup Note* + +Auditd Manager subscribes to the kernel and receives events as they occur without any additional configuration. +However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from. +- For this detection rule no additional audit rules are required. + diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-linux-process-calling-the-metadata-service.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-linux-process-calling-the-metadata-service.asciidoc new file mode 100644 index 0000000000..461b1fb5f3 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-linux-process-calling-the-metadata-service.asciidoc @@ -0,0 +1,123 @@ +[[prebuilt-rule-8-13-10-unusual-linux-process-calling-the-metadata-service]] +=== Unusual Linux Process Calling the Metadata Service + +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. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-45m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Credential Access + +*Version*: 104 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Auditd Manager + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditd Manager Integration Setup* + +The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel. +Auditd 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. + + +*The following steps should be executed in order to add the Elastic Agent System integration "auditd_manager" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Auditd Manager” and select the integration to see more details about it. +- Click “Add Auditd Manager”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “auditd manager” to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/auditd_manager[helper guide]. + + +*Rule Specific Setup Note* + +Auditd Manager subscribes to the kernel and receives events as they occur without any additional configuration. +However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from. +- For this detection rule no additional audit rules are required. + + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Cloud Instance Metadata API +** ID: T1552.005 +** Reference URL: https://attack.mitre.org/techniques/T1552/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-linux-process-discovery-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-linux-process-discovery-activity.asciidoc new file mode 100644 index 0000000000..522558e549 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-linux-process-discovery-activity.asciidoc @@ -0,0 +1,119 @@ +[[prebuilt-rule-8-13-10-unusual-linux-process-discovery-activity]] +=== Unusual Linux Process Discovery Activity + +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. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-45m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Discovery + +*Version*: 104 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Auditd Manager + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditd Manager Integration Setup* + +The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel. +Auditd 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. + + +*The following steps should be executed in order to add the Elastic Agent System integration "auditd_manager" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Auditd Manager” and select the integration to see more details about it. +- Click “Add Auditd Manager”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “auditd manager” to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/auditd_manager[helper guide]. + + +*Rule Specific Setup Note* + +Auditd Manager subscribes to the kernel and receives events as they occur without any additional configuration. +However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from. +- For this detection rule no additional audit rules are required. + + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: Process Discovery +** ID: T1057 +** Reference URL: https://attack.mitre.org/techniques/T1057/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-linux-system-information-discovery-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-linux-system-information-discovery-activity.asciidoc new file mode 100644 index 0000000000..bf258c2a06 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-linux-system-information-discovery-activity.asciidoc @@ -0,0 +1,119 @@ +[[prebuilt-rule-8-13-10-unusual-linux-system-information-discovery-activity]] +=== Unusual Linux System Information Discovery Activity + +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. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-45m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Discovery + +*Version*: 104 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Auditd Manager + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditd Manager Integration Setup* + +The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel. +Auditd 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. + + +*The following steps should be executed in order to add the Elastic Agent System integration "auditd_manager" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Auditd Manager” and select the integration to see more details about it. +- Click “Add Auditd Manager”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “auditd manager” to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/auditd_manager[helper guide]. + + +*Rule Specific Setup Note* + +Auditd Manager subscribes to the kernel and receives events as they occur without any additional configuration. +However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from. +- For this detection rule no additional audit rules are required. + + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Information Discovery +** ID: T1082 +** Reference URL: https://attack.mitre.org/techniques/T1082/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-linux-user-calling-the-metadata-service.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-linux-user-calling-the-metadata-service.asciidoc new file mode 100644 index 0000000000..2164806358 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-linux-user-calling-the-metadata-service.asciidoc @@ -0,0 +1,123 @@ +[[prebuilt-rule-8-13-10-unusual-linux-user-calling-the-metadata-service]] +=== Unusual Linux User Calling the Metadata Service + +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. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-45m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Credential Access + +*Version*: 104 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Auditd Manager + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditd Manager Integration Setup* + +The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel. +Auditd 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. + + +*The following steps should be executed in order to add the Elastic Agent System integration "auditd_manager" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Auditd Manager” and select the integration to see more details about it. +- Click “Add Auditd Manager”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “auditd manager” to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/auditd_manager[helper guide]. + + +*Rule Specific Setup Note* + +Auditd Manager subscribes to the kernel and receives events as they occur without any additional configuration. +However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from. +- For this detection rule no additional audit rules are required. + + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Cloud Instance Metadata API +** ID: T1552.005 +** Reference URL: https://attack.mitre.org/techniques/T1552/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-linux-user-discovery-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-linux-user-discovery-activity.asciidoc new file mode 100644 index 0000000000..5456dc7f22 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-linux-user-discovery-activity.asciidoc @@ -0,0 +1,119 @@ +[[prebuilt-rule-8-13-10-unusual-linux-user-discovery-activity]] +=== Unusual Linux User Discovery Activity + +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. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-45m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Discovery + +*Version*: 105 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Auditd Manager + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditd Manager Integration Setup* + +The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel. +Auditd 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. + + +*The following steps should be executed in order to add the Elastic Agent System integration "auditd_manager" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Auditd Manager” and select the integration to see more details about it. +- Click “Add Auditd Manager”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “auditd manager” to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/auditd_manager[helper guide]. + + +*Rule Specific Setup Note* + +Auditd Manager subscribes to the kernel and receives events as they occur without any additional configuration. +However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from. +- For this detection rule no additional audit rules are required. + + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Owner/User Discovery +** ID: T1033 +** Reference URL: https://attack.mitre.org/techniques/T1033/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-linux-username.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-linux-username.asciidoc new file mode 100644 index 0000000000..97bd1612db --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-linux-username.asciidoc @@ -0,0 +1,136 @@ +[[prebuilt-rule-8-13-10-unusual-linux-username]] +=== Unusual Linux Username + +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. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-45m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Initial Access + +*Version*: 104 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating an Unusual Linux User* + +Detection alerts from this rule indicate activity for a Linux user name that is rare and unusual. Here are some possible avenues of investigation: +- 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? +- 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. +- 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. + +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Auditd Manager + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditd Manager Integration Setup* + +The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel. +Auditd 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. + + +*The following steps should be executed in order to add the Elastic Agent System integration "auditd_manager" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Auditd Manager” and select the integration to see more details about it. +- Click “Add Auditd Manager”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “auditd manager” to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/auditd_manager[helper guide]. + + +*Rule Specific Setup Note* + +Auditd Manager subscribes to the kernel and receives events as they occur without any additional configuration. +However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from. +- For this detection rule no additional audit rules are required. + + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-login-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-login-activity.asciidoc new file mode 100644 index 0000000000..1a0717b7ff --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-login-activity.asciidoc @@ -0,0 +1,138 @@ +[[prebuilt-rule-8-13-10-unusual-login-activity]] +=== Unusual Login Activity + +Identifies an unusually high number of authentication attempts. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-45m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html + +*Tags*: + +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Credential Access + +*Version*: 104 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Auditd Manager +- System + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditd Manager Integration Setup* + +The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel. +Auditd 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. + + +*The following steps should be executed in order to add the Elastic Agent System integration "auditd_manager" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Auditd Manager” and select the integration to see more details about it. +- Click “Add Auditd Manager”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “auditd manager” to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/auditd_manager[helper guide]. + + +*Rule Specific Setup Note* + +Auditd Manager subscribes to the kernel and receives events as they occur without any additional configuration. +However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from. +- For this detection rule no additional audit rules are required. + + +*System Integration Setup* + +The System integration allows you to collect system logs and metrics from your servers with Elastic Agent. + + +*The following steps should be executed in order to add the Elastic Agent System integration "system" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “System” and select the integration to see more details about it. +- Click “Add System”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “system” to an existing or a new agent policy, and deploy the agent on your system from which system log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/system[helper guide]. + + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-network-destination-domain-name.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-network-destination-domain-name.asciidoc new file mode 100644 index 0000000000..c6df903d31 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-network-destination-domain-name.asciidoc @@ -0,0 +1,107 @@ +[[prebuilt-rule-8-13-10-unusual-network-destination-domain-name]] +=== Unusual Network Destination Domain Name + +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. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-45m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html + +*Tags*: + +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning + +*Version*: 104 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Auditd Manager + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditd Manager Integration Setup* + +The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel. +Auditd 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. + + +*The following steps should be executed in order to add the Elastic Agent System integration "auditd_manager" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Auditd Manager” and select the integration to see more details about it. +- Click “Add Auditd Manager”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “auditd manager” to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/auditd_manager[helper guide]. + + +*Rule Specific Setup Note* + +Auditd Manager subscribes to the kernel and receives events as they occur without any additional configuration. +However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from. +- For this detection rule no additional audit rules are required. + diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-process-for-a-linux-host.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-process-for-a-linux-host.asciidoc new file mode 100644 index 0000000000..853f0f3f4c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-process-for-a-linux-host.asciidoc @@ -0,0 +1,176 @@ +[[prebuilt-rule-8-13-10-unusual-process-for-a-linux-host]] +=== Unusual Process For a Linux Host + +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. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-45m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Persistence + +*Version*: 105 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Unusual Process For a Linux Host* + + +Searching 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. + +This rule uses a machine learning job to detect a Linux process that is rare and unusual for an individual Linux host in your environment. + + +*Possible investigation steps* + + +- 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. +- Investigate other alerts associated with the user/host during the past 48 hours. +- 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? +- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations. +- 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. +- 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. + + +*False Positive Analysis* + + +- If this activity is related to new benign software installation activity, consider adding exceptions — preferably with a combination of user and command line conditions. +- 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. + + +*Response and Remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved hosts to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- 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. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- 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). + + +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Auditd Manager + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditd Manager Integration Setup* + +The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel. +Auditd 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. + + +*The following steps should be executed in order to add the Elastic Agent System integration "auditd_manager" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Auditd Manager” and select the integration to see more details about it. +- Click “Add Auditd Manager”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “auditd manager” to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/auditd_manager[helper guide]. + + +*Rule Specific Setup Note* + +Auditd Manager subscribes to the kernel and receives events as they occur without any additional configuration. +However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from. +- For this detection rule no additional audit rules are required. + + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Sub-technique: +** Name: Systemd Service +** ID: T1543.002 +** Reference URL: https://attack.mitre.org/techniques/T1543/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-process-for-a-windows-host.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-process-for-a-windows-host.asciidoc new file mode 100644 index 0000000000..a06135d9ba --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-process-for-a-windows-host.asciidoc @@ -0,0 +1,195 @@ +[[prebuilt-rule-8-13-10-unusual-process-for-a-windows-host]] +=== Unusual Process For a Windows Host + +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. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-45m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Persistence +* Resources: Investigation Guide + +*Version*: 109 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Unusual Process For a Windows Host* + + +Searching 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. + +This rule uses a machine learning job to detect a Windows process that is rare and unusual for an individual Windows host in your environment. + +> **Note**: +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html[Osquery Markdown Plugin] introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. + + +*Possible investigation steps* + + +- 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. + - 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. + - Investigate the process metadata — such as the digital signature, directory, etc. — to obtain more context that can indicate whether the executable is associated with an expected software vendor or package. +- Investigate other alerts associated with the user/host during the past 48 hours. +- 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? +- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations. +- 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. +- 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. +- Examine the host for derived artifacts that indicate suspicious activities: + - Analyze the process executable using a private sandboxed analysis system. + - Observe and collect information about the following activities in both the sandbox and the alert subject host: + - Attempts to contact external domains and addresses. + - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`. + - Examine the DNS cache for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve DNS Cache","query":"SELECT * FROM dns_cache"}} + - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree. + - Examine the host services for suspicious or anomalous entries. + - !{osquery{"label":"Osquery - Retrieve All Services","query":"SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"}} + - !{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"}} + - !{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"}} + - 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. + + +*False Positive Analysis* + + +- If this activity is related to new benign software installation activity, consider adding exceptions — preferably with a combination of user and command line conditions. +- 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. + + +*Related Rules* + + +- Unusual Process For a Windows Host - 6d448b96-c922-4adb-b51c-b767f1ea5b76 +- Unusual Windows Path Activity - 445a342e-03fb-42d0-8656-0367eb2dead5 +- Unusual Windows Process Calling the Metadata Service - abae61a8-c560-4dbd-acca-1e1438bff36b + + +*Response and Remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Isolate the involved hosts to prevent further post-compromise behavior. +- If the triage identified malware, search the environment for additional compromised hosts. + - Implement temporary network rules, procedures, and segmentation to contain the malware. + - Stop suspicious processes. + - Immediately block the identified indicators of compromise (IoCs). + - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system. +- Remove and block malicious artifacts identified during triage. +- 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. +- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components. +- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. +- 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). + + +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Windows + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Windows Integration Setup* + +The Windows integration allows you to monitor the Windows OS, services, applications, and more. + + +*The following steps should be executed in order to add the Elastic Agent System integration "windows" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Windows” and select the integration to see more details about it. +- Click “Add Windows”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “windows” to an existing or a new agent policy, and deploy the agent on your system from which windows log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/windows[helper guide]. + + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Sub-technique: +** Name: Windows Service +** ID: T1543.003 +** Reference URL: https://attack.mitre.org/techniques/T1543/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-source-ip-for-a-user-to-logon-from.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-source-ip-for-a-user-to-logon-from.asciidoc new file mode 100644 index 0000000000..e4ff72886f --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-source-ip-for-a-user-to-logon-from.asciidoc @@ -0,0 +1,138 @@ +[[prebuilt-rule-8-13-10-unusual-source-ip-for-a-user-to-logon-from]] +=== Unusual Source IP for a User to Logon from + +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. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-30m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html + +*Tags*: + +* Use Case: Identity and Access Audit +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Initial Access + +*Version*: 104 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Auditd Manager +- System + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditd Manager Integration Setup* + +The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel. +Auditd 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. + + +*The following steps should be executed in order to add the Elastic Agent System integration "auditd_manager" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Auditd Manager” and select the integration to see more details about it. +- Click “Add Auditd Manager”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “auditd manager” to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/auditd_manager[helper guide]. + + +*Rule Specific Setup Note* + +Auditd Manager subscribes to the kernel and receives events as they occur without any additional configuration. +However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from. +- For this detection rule no additional audit rules are required. + + +*System Integration Setup* + +The System integration allows you to collect system logs and metrics from your servers with Elastic Agent. + + +*The following steps should be executed in order to add the Elastic Agent System integration "system" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “System” and select the integration to see more details about it. +- Click “Add System”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “system” to an existing or a new agent policy, and deploy the agent on your system from which system log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/system[helper guide]. + + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-sudo-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-sudo-activity.asciidoc new file mode 100644 index 0000000000..0b78a31727 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-sudo-activity.asciidoc @@ -0,0 +1,127 @@ +[[prebuilt-rule-8-13-10-unusual-sudo-activity]] +=== Unusual Sudo Activity + +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. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-45m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Privilege Escalation + +*Version*: 104 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Auditd Manager + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditd Manager Integration Setup* + +The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel. +Auditd 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. + + +*The following steps should be executed in order to add the Elastic Agent System integration "auditd_manager" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Auditd Manager” and select the integration to see more details about it. +- Click “Add Auditd Manager”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “auditd manager” to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/auditd_manager[helper guide]. + + +*Rule Specific Setup Note* + +Auditd Manager subscribes to the kernel and receives events as they occur without any additional configuration. +However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from. +- For this detection rule no additional audit rules are required. + + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Abuse Elevation Control Mechanism +** ID: T1548 +** Reference URL: https://attack.mitre.org/techniques/T1548/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-web-request.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-web-request.asciidoc new file mode 100644 index 0000000000..465e563523 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-web-request.asciidoc @@ -0,0 +1,115 @@ +[[prebuilt-rule-8-13-10-unusual-web-request]] +=== Unusual Web Request + +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. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-45m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html + +*Tags*: + +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Command and Control + +*Version*: 104 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Network Packet Capture + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Network Packet Capture Integration Setup* + +The 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 — 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. + + +*The following steps should be executed in order to add the Elastic Agent System integration "network_traffic" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Network Packet Capture” and select the integration to see more details about it. +- Click “Add Network Packet Capture”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “network_traffic” to an existing or a new agent policy, and deploy the agent on your system from which network log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/network_traffic[helper guide]. + + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Sub-technique: +** Name: Web Protocols +** ID: T1071.001 +** Reference URL: https://attack.mitre.org/techniques/T1071/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-web-user-agent.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-web-user-agent.asciidoc new file mode 100644 index 0000000000..15e4dd9a7b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-web-user-agent.asciidoc @@ -0,0 +1,115 @@ +[[prebuilt-rule-8-13-10-unusual-web-user-agent]] +=== Unusual Web User Agent + +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. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-45m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html + +*Tags*: + +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Command and Control + +*Version*: 104 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Network Packet Capture + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Network Packet Capture Integration Setup* + +The 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 — 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. + + +*The following steps should be executed in order to add the Elastic Agent System integration "network_traffic" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Network Packet Capture” and select the integration to see more details about it. +- Click “Add Network Packet Capture”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “network_traffic” to an existing or a new agent policy, and deploy the agent on your system from which network log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/network_traffic[helper guide]. + + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Command and Control +** ID: TA0011 +** Reference URL: https://attack.mitre.org/tactics/TA0011/ +* Technique: +** Name: Application Layer Protocol +** ID: T1071 +** Reference URL: https://attack.mitre.org/techniques/T1071/ +* Sub-technique: +** Name: Web Protocols +** ID: T1071.001 +** Reference URL: https://attack.mitre.org/techniques/T1071/001/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-windows-network-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-windows-network-activity.asciidoc new file mode 100644 index 0000000000..670165ad89 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-windows-network-activity.asciidoc @@ -0,0 +1,120 @@ +[[prebuilt-rule-8-13-10-unusual-windows-network-activity]] +=== Unusual Windows Network Activity + +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. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-45m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning + +*Version*: 104 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Unusual Network Activity* + +Detection 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: +- Consider the IP addresses, protocol and ports. Are these used by normal but infrequent network workflows? Are they expected or unexpected? +- 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. +- 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? +- 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. +- 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. +- 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. +- 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. + +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Windows + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Windows Integration Setup* + +The Windows integration allows you to monitor the Windows OS, services, applications, and more. + + +*The following steps should be executed in order to add the Elastic Agent System integration "windows" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Windows” and select the integration to see more details about it. +- Click “Add Windows”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “windows” to an existing or a new agent policy, and deploy the agent on your system from which windows log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/windows[helper guide]. + diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-windows-path-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-windows-path-activity.asciidoc new file mode 100644 index 0000000000..1460ea3974 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-windows-path-activity.asciidoc @@ -0,0 +1,130 @@ +[[prebuilt-rule-8-13-10-unusual-windows-path-activity]] +=== Unusual Windows Path Activity + +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. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-45m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Persistence +* Tactic: Execution + +*Version*: 105 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Windows + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Windows Integration Setup* + +The Windows integration allows you to monitor the Windows OS, services, applications, and more. + + +*The following steps should be executed in order to add the Elastic Agent System integration "windows" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Windows” and select the integration to see more details about it. +- Click “Add Windows”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “windows” to an existing or a new agent policy, and deploy the agent on your system from which windows log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/windows[helper guide]. + + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Sub-technique: +** Name: Windows Service +** ID: T1543.003 +** Reference URL: https://attack.mitre.org/techniques/T1543/003/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: User Execution +** ID: T1204 +** Reference URL: https://attack.mitre.org/techniques/T1204/ +* Sub-technique: +** Name: Malicious File +** ID: T1204.002 +** Reference URL: https://attack.mitre.org/techniques/T1204/002/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-windows-process-calling-the-metadata-service.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-windows-process-calling-the-metadata-service.asciidoc new file mode 100644 index 0000000000..46bb229bab --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-windows-process-calling-the-metadata-service.asciidoc @@ -0,0 +1,115 @@ +[[prebuilt-rule-8-13-10-unusual-windows-process-calling-the-metadata-service]] +=== Unusual Windows Process Calling the Metadata Service + +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. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-45m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Credential Access + +*Version*: 104 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Windows + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Windows Integration Setup* + +The Windows integration allows you to monitor the Windows OS, services, applications, and more. + + +*The following steps should be executed in order to add the Elastic Agent System integration "windows" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Windows” and select the integration to see more details about it. +- Click “Add Windows”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “windows” to an existing or a new agent policy, and deploy the agent on your system from which windows log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/windows[helper guide]. + + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Cloud Instance Metadata API +** ID: T1552.005 +** Reference URL: https://attack.mitre.org/techniques/T1552/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-windows-remote-user.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-windows-remote-user.asciidoc new file mode 100644 index 0000000000..7eee8e9a60 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-windows-remote-user.asciidoc @@ -0,0 +1,127 @@ +[[prebuilt-rule-8-13-10-unusual-windows-remote-user]] +=== Unusual Windows Remote User + +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. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-45m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Initial Access + +*Version*: 104 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating an Unusual Windows User* + +Detection alerts from this rule indicate activity for a rare and unusual Windows RDP (remote desktop) user. Here are some possible avenues of investigation: +- 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? +- 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? + +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Windows + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Windows Integration Setup* + +The Windows integration allows you to monitor the Windows OS, services, applications, and more. + + +*The following steps should be executed in order to add the Elastic Agent System integration "windows" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Windows” and select the integration to see more details about it. +- Click “Add Windows”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “windows” to an existing or a new agent policy, and deploy the agent on your system from which windows log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/windows[helper guide]. + + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-windows-service.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-windows-service.asciidoc new file mode 100644 index 0000000000..b6aa631a20 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-windows-service.asciidoc @@ -0,0 +1,117 @@ +[[prebuilt-rule-8-13-10-unusual-windows-service]] +=== Unusual Windows Service + +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. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-45m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Persistence + +*Version*: 104 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Windows + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Windows Integration Setup* + +The Windows integration allows you to monitor the Windows OS, services, applications, and more. + + +*The following steps should be executed in order to add the Elastic Agent System integration "windows" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Windows” and select the integration to see more details about it. +- Click “Add Windows”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “windows” to an existing or a new agent policy, and deploy the agent on your system from which windows log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/windows[helper guide]. + + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Sub-technique: +** Name: Windows Service +** ID: T1543.003 +** Reference URL: https://attack.mitre.org/techniques/T1543/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-windows-user-calling-the-metadata-service.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-windows-user-calling-the-metadata-service.asciidoc new file mode 100644 index 0000000000..bc84f5da4c --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-windows-user-calling-the-metadata-service.asciidoc @@ -0,0 +1,115 @@ +[[prebuilt-rule-8-13-10-unusual-windows-user-calling-the-metadata-service]] +=== Unusual Windows User Calling the Metadata Service + +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. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-45m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: None + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Credential Access + +*Version*: 104 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Windows + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Windows Integration Setup* + +The Windows integration allows you to monitor the Windows OS, services, applications, and more. + + +*The following steps should be executed in order to add the Elastic Agent System integration "windows" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Windows” and select the integration to see more details about it. +- Click “Add Windows”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “windows” to an existing or a new agent policy, and deploy the agent on your system from which windows log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/windows[helper guide]. + + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Unsecured Credentials +** ID: T1552 +** Reference URL: https://attack.mitre.org/techniques/T1552/ +* Sub-technique: +** Name: Cloud Instance Metadata API +** ID: T1552.005 +** Reference URL: https://attack.mitre.org/techniques/T1552/005/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-windows-user-privilege-elevation-activity.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-windows-user-privilege-elevation-activity.asciidoc new file mode 100644 index 0000000000..5b93fe2264 --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-windows-user-privilege-elevation-activity.asciidoc @@ -0,0 +1,109 @@ +[[prebuilt-rule-8-13-10-unusual-windows-user-privilege-elevation-activity]] +=== Unusual Windows User Privilege Elevation Activity + +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. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-45m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Privilege Escalation + +*Version*: 104 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Windows + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Windows Integration Setup* + +The Windows integration allows you to monitor the Windows OS, services, applications, and more. + + +*The following steps should be executed in order to add the Elastic Agent System integration "windows" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Windows” and select the integration to see more details about it. +- Click “Add Windows”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “windows” to an existing or a new agent policy, and deploy the agent on your system from which windows log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/windows[helper guide]. + + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-windows-username.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-windows-username.asciidoc new file mode 100644 index 0000000000..14967bd7ae --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rule-8-13-10-unusual-windows-username.asciidoc @@ -0,0 +1,137 @@ +[[prebuilt-rule-8-13-10-unusual-windows-username]] +=== Unusual Windows Username + +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. + +*Rule type*: machine_learning + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 15m + +*Searches indices from*: now-45m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Rule Type: ML +* Rule Type: Machine Learning +* Tactic: Initial Access + +*Version*: 105 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating an Unusual Windows User* + +Detection alerts from this rule indicate activity for a Windows user name that is rare and unusual. Here are some possible avenues of investigation: +- 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? +- 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. +- 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. +- 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. + +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Windows + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Windows Integration Setup* + +The Windows integration allows you to monitor the Windows OS, services, applications, and more. + + +*The following steps should be executed in order to add the Elastic Agent System integration "windows" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Windows” and select the integration to see more details about it. +- Click “Add Windows”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “windows” to an existing or a new agent policy, and deploy the agent on your system from which windows log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/windows[helper guide]. + + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Initial Access +** ID: TA0001 +** Reference URL: https://attack.mitre.org/tactics/TA0001/ +* Technique: +** Name: Valid Accounts +** ID: T1078 +** Reference URL: https://attack.mitre.org/techniques/T1078/ +* Sub-technique: +** Name: Domain Accounts +** ID: T1078.002 +** Reference URL: https://attack.mitre.org/techniques/T1078/002/ +* Sub-technique: +** Name: Local Accounts +** ID: T1078.003 +** Reference URL: https://attack.mitre.org/techniques/T1078/003/ diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rules-8-13-10-appendix.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rules-8-13-10-appendix.asciidoc new file mode 100644 index 0000000000..508ad232fc --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rules-8-13-10-appendix.asciidoc @@ -0,0 +1,71 @@ +["appendix",role="exclude",id="prebuilt-rule-8-13-10-prebuilt-rules-8-13-10-appendix"] += Downloadable rule update v8.13.10 + +This section lists all updates associated with version 8.13.10 of the Fleet integration *Prebuilt Security Detection Rules*. + + +include::prebuilt-rule-8-13-10-aws-iam-user-created-access-keys-for-another-user.asciidoc[] +include::prebuilt-rule-8-13-10-multiple-okta-user-authentication-events-with-client-address.asciidoc[] +include::prebuilt-rule-8-13-10-multiple-okta-user-authentication-events-with-same-device-token-hash.asciidoc[] +include::prebuilt-rule-8-13-10-high-number-of-okta-device-token-cookies-generated-for-authentication.asciidoc[] +include::prebuilt-rule-8-13-10-rapid7-threat-command-cves-correlation.asciidoc[] +include::prebuilt-rule-8-13-10-potential-wpad-spoofing-via-dns-record-creation.asciidoc[] +include::prebuilt-rule-8-13-10-ntds-dump-via-wbadmin.asciidoc[] +include::prebuilt-rule-8-13-10-dns-global-query-block-list-modified-or-disabled.asciidoc[] +include::prebuilt-rule-8-13-10-unsigned-dll-loaded-by-dns-service.asciidoc[] +include::prebuilt-rule-8-13-10-potential-privilege-escalation-via-service-imagepath-modification.asciidoc[] +include::prebuilt-rule-8-13-10-agent-spoofing-multiple-hosts-using-same-agent.asciidoc[] +include::prebuilt-rule-8-13-10-spike-in-aws-error-messages.asciidoc[] +include::prebuilt-rule-8-13-10-rare-aws-error-code.asciidoc[] +include::prebuilt-rule-8-13-10-unusual-city-for-an-aws-command.asciidoc[] +include::prebuilt-rule-8-13-10-unusual-country-for-an-aws-command.asciidoc[] +include::prebuilt-rule-8-13-10-unusual-aws-command-for-a-user.asciidoc[] +include::prebuilt-rule-8-13-10-aws-security-token-service-sts-assumerole-usage.asciidoc[] +include::prebuilt-rule-8-13-10-potential-persistence-via-file-modification.asciidoc[] +include::prebuilt-rule-8-13-10-okta-user-sessions-started-from-different-geolocations.asciidoc[] +include::prebuilt-rule-8-13-10-dns-tunneling.asciidoc[] +include::prebuilt-rule-8-13-10-unusual-dns-activity.asciidoc[] +include::prebuilt-rule-8-13-10-unusual-web-request.asciidoc[] +include::prebuilt-rule-8-13-10-unusual-web-user-agent.asciidoc[] +include::prebuilt-rule-8-13-10-spike-in-failed-logon-events.asciidoc[] +include::prebuilt-rule-8-13-10-spike-in-logon-events.asciidoc[] +include::prebuilt-rule-8-13-10-spike-in-successful-logon-events-from-a-source-ip.asciidoc[] +include::prebuilt-rule-8-13-10-unusual-linux-process-calling-the-metadata-service.asciidoc[] +include::prebuilt-rule-8-13-10-unusual-linux-user-calling-the-metadata-service.asciidoc[] +include::prebuilt-rule-8-13-10-unusual-login-activity.asciidoc[] +include::prebuilt-rule-8-13-10-unusual-windows-process-calling-the-metadata-service.asciidoc[] +include::prebuilt-rule-8-13-10-unusual-windows-user-calling-the-metadata-service.asciidoc[] +include::prebuilt-rule-8-13-10-unusual-linux-system-information-discovery-activity.asciidoc[] +include::prebuilt-rule-8-13-10-unusual-linux-network-configuration-discovery.asciidoc[] +include::prebuilt-rule-8-13-10-unusual-linux-network-connection-discovery.asciidoc[] +include::prebuilt-rule-8-13-10-unusual-linux-process-discovery-activity.asciidoc[] +include::prebuilt-rule-8-13-10-unusual-linux-user-discovery-activity.asciidoc[] +include::prebuilt-rule-8-13-10-suspicious-powershell-script.asciidoc[] +include::prebuilt-rule-8-13-10-unusual-hour-for-a-user-to-logon.asciidoc[] +include::prebuilt-rule-8-13-10-unusual-source-ip-for-a-user-to-logon-from.asciidoc[] +include::prebuilt-rule-8-13-10-rare-user-logon.asciidoc[] +include::prebuilt-rule-8-13-10-unusual-linux-username.asciidoc[] +include::prebuilt-rule-8-13-10-unusual-windows-username.asciidoc[] +include::prebuilt-rule-8-13-10-unusual-windows-remote-user.asciidoc[] +include::prebuilt-rule-8-13-10-spike-in-firewall-denies.asciidoc[] +include::prebuilt-rule-8-13-10-spike-in-network-traffic.asciidoc[] +include::prebuilt-rule-8-13-10-unusual-linux-network-activity.asciidoc[] +include::prebuilt-rule-8-13-10-unusual-linux-network-port-activity.asciidoc[] +include::prebuilt-rule-8-13-10-unusual-network-destination-domain-name.asciidoc[] +include::prebuilt-rule-8-13-10-network-traffic-to-rare-destination-country.asciidoc[] +include::prebuilt-rule-8-13-10-spike-in-network-traffic-to-a-country.asciidoc[] +include::prebuilt-rule-8-13-10-unusual-windows-network-activity.asciidoc[] +include::prebuilt-rule-8-13-10-anomalous-process-for-a-linux-population.asciidoc[] +include::prebuilt-rule-8-13-10-unusual-process-for-a-linux-host.asciidoc[] +include::prebuilt-rule-8-13-10-unusual-process-for-a-windows-host.asciidoc[] +include::prebuilt-rule-8-13-10-unusual-windows-path-activity.asciidoc[] +include::prebuilt-rule-8-13-10-anomalous-process-for-a-windows-population.asciidoc[] +include::prebuilt-rule-8-13-10-anomalous-windows-process-creation.asciidoc[] +include::prebuilt-rule-8-13-10-unusual-windows-service.asciidoc[] +include::prebuilt-rule-8-13-10-unusual-sudo-activity.asciidoc[] +include::prebuilt-rule-8-13-10-unusual-windows-user-privilege-elevation-activity.asciidoc[] +include::prebuilt-rule-8-13-10-anomalous-linux-compiler-activity.asciidoc[] +include::prebuilt-rule-8-13-10-threat-intel-ip-address-indicator-match.asciidoc[] +include::prebuilt-rule-8-13-10-threat-intel-hash-indicator-match.asciidoc[] +include::prebuilt-rule-8-13-10-threat-intel-windows-registry-indicator-match.asciidoc[] +include::prebuilt-rule-8-13-10-threat-intel-url-indicator-match.asciidoc[] diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rules-8-13-10-summary.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rules-8-13-10-summary.asciidoc new file mode 100644 index 0000000000..6b6232758b --- /dev/null +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rules-8-13-10-summary.asciidoc @@ -0,0 +1,142 @@ +[[prebuilt-rule-8-13-10-prebuilt-rules-8-13-10-summary]] +[role="xpack"] +== Update v8.13.10 + +This section lists all updates associated with version 8.13.10 of the Fleet integration *Prebuilt Security Detection Rules*. + + +[width="100%",options="header"] +|============================================== +|Rule |Description |Status |Version + +|<> | 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. | new | 1 + +|<> | 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. | new | 1 + +|<> | 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. | new | 1 + +|<> | 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. | new | 1 + +|<> | 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. | new | 1 + +|<> | 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. | new | 1 + +|<> | 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. | new | 1 + +|<> | 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. | new | 1 + +|<> | 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. | new | 1 + +|<> | 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. | new | 1 + +|<> | 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. | update | 102 + +|<> | 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. | update | 209 + +|<> | 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. | update | 209 + +|<> | 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). | update | 209 + +|<> | 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). | update | 209 + +|<> | 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. | update | 209 + +|<> | 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. | update | 207 + +|<> | 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. | update | 2 + +|<> | 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. | update | 101 + +|<> | 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. | update | 104 + +|<> | 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. | update | 104 + +|<> | 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. | update | 104 + +|<> | 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. | update | 104 + +|<> | 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. | update | 105 + +|<> | 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. | update | 104 + +|<> | 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. | update | 105 + +|<> | 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. | update | 104 + +|<> | 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. | update | 104 + +|<> | Identifies an unusually high number of authentication attempts. | update | 104 + +|<> | 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. | update | 104 + +|<> | 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. | update | 104 + +|<> | 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. | update | 104 + +|<> | 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. | update | 105 + +|<> | 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. | update | 104 + +|<> | 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. | update | 104 + +|<> | 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. | update | 105 + +|<> | 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. | update | 105 + +|<> | 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. | update | 105 + +|<> | 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. | update | 104 + +|<> | 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. | update | 105 + +|<> | 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. | update | 104 + +|<> | 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. | update | 105 + +|<> | 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. | update | 104 + +|<> | 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. | update | 104 + +|<> | 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. | update | 104 + +|<> | 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. | update | 104 + +|<> | 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. | update | 104 + +|<> | 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. | update | 104 + +|<> | 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. | update | 104 + +|<> | 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. | update | 105 + +|<> | 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. | update | 104 + +|<> | 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. | update | 105 + +|<> | 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. | update | 105 + +|<> | 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. | update | 109 + +|<> | 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. | update | 105 + +|<> | 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. | update | 106 + +|<> | 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. | update | 106 + +|<> | 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. | update | 104 + +|<> | 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. | update | 104 + +|<> | 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. | update | 104 + +|<> | 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. | update | 104 + +|<> | This rule is triggered when an IP address indicator from the Threat Intel Filebeat module or integrations has a match against a network event. | update | 7 + +|<> | 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. | update | 8 + +|<> | 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. | update | 7 + +|<> | 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. | update | 7 + +|============================================== diff --git a/docs/detections/prebuilt-rules/prebuilt-rules-downloadable-updates.asciidoc b/docs/detections/prebuilt-rules/prebuilt-rules-downloadable-updates.asciidoc index 09265c6c88..0c4ac7a6ae 100644 --- a/docs/detections/prebuilt-rules/prebuilt-rules-downloadable-updates.asciidoc +++ b/docs/detections/prebuilt-rules/prebuilt-rules-downloadable-updates.asciidoc @@ -13,6 +13,10 @@ For previous rule updates, please navigate to the https://www.elastic.co/guide/e |Update version |Date | New rules | Updated rules | Notes +|<> | 25 Jun 2024 | 10 | 55 | +This release includes new rules for Windows, Okta and AWS integration and tuned rules for Okta and AWS. New rules for Windows include detection for defense evasion, privilege escalation, and credential access. New rules for AWS include detection for persistence. New rules for Okta include detection for credential access. Additionally, significant rule tuning for Okta and AWS rules has been added for better rule efficacy and performance. + + |<> | 11 Jun 2024 | 24 | 29 | This release includes new rules for Linux and AWS integration and tuned rules for Windows , Linux, AWS and Microsoft 365. New rules for Linux include detection for persistence. New rules for AWS include detection for execution, persistence, credential access, impact, exfiltration, privilege escalation and discovery. Additionally, significant rule tuning for Windows ,Linux and Microsoft 365 rules has been added for better rule efficacy and performance. @@ -74,3 +78,4 @@ include::downloadable-packages/8-13-6/prebuilt-rules-8-13-6-summary.asciidoc[lev include::downloadable-packages/8-13-7/prebuilt-rules-8-13-7-summary.asciidoc[leveloffset=+1] include::downloadable-packages/8-13-8/prebuilt-rules-8-13-8-summary.asciidoc[leveloffset=+1] include::downloadable-packages/8-13-9/prebuilt-rules-8-13-9-summary.asciidoc[leveloffset=+1] +include::downloadable-packages/8-13-10/prebuilt-rules-8-13-10-summary.asciidoc[leveloffset=+1] diff --git a/docs/detections/prebuilt-rules/prebuilt-rules-reference.asciidoc b/docs/detections/prebuilt-rules/prebuilt-rules-reference.asciidoc index aec9e473be..5950c53088 100644 --- a/docs/detections/prebuilt-rules/prebuilt-rules-reference.asciidoc +++ b/docs/detections/prebuilt-rules/prebuilt-rules-reference.asciidoc @@ -104,6 +104,8 @@ and their rule type is `machine_learning`. |<> |Identifies the addition of a user to a specified group in AWS Identity and Access Management (IAM). |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Use Case: Identity and Access Audit], [Tactic: Credential Access], [Tactic: Persistence], [Resources: Investigation Guide] |None |209 +|<> |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. |[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] |8.13.0 |1 + |<> |Identifies attempts to disable or schedule the deletion of an AWS KMS Customer Managed Key (CMK). Deleting an AWS KMS key is destructive and potentially dangerous. It deletes the key material and all metadata associated with the KMS key and is irreversible. After a KMS key is deleted, the data that was encrypted under that KMS key can no longer be decrypted, which means that data becomes unrecoverable. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS KMS], [Use Case: Log Auditing], [Tactic: Impact] |None |106 |<> |Identifies when an AWS Lambda function is created or updated. AWS Lambda lets you run code without provisioning or managing servers. Adversaries can create or update Lambda functions to execute malicious code, exfiltrate data, or escalate privileges. This is a [building block rule](https://www.elastic.co/guide/en/security/current/building-block-rule.html) that does not generate alerts, but signals when a Lambda function is created or updated that matches the rule's conditions. To generate alerts, create a rule that uses this signal as a building block. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Lambda], [Use Case: Asset Visibility], [Tactic: Execution] |8.9.0 |1 @@ -160,7 +162,7 @@ and their rule type is `machine_learning`. |<> |Identifies a change to an AWS Security Group Configuration. A security group is like a virtual firewall, and modifying configurations may allow unauthorized access. Threat actors may abuse this to establish persistence, exfiltrate data, or pivot in an AWS environment. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS EC2], [Use Case: Network Security Monitoring], [Tactic: Persistence] |None |206 -|<> |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. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS STS], [Use Case: Identity and Access Audit], [Tactic: Privilege Escalation] |None |206 +|<> |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. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS STS], [Use Case: Identity and Access Audit], [Tactic: Privilege Escalation] |8.9.0 |207 |<> |Detects the first occurrence of a user identity accessing AWS Systems Manager (SSM) SecureString parameters using the GetParameter or GetParameters API actions with credentials in the request parameters. This could indicate that the user is accessing sensitive information. This rule detects when a user accesses a SecureString parameter with the `withDecryption` parameter set to true. This is a [NewTerms](https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-new-terms-rule) rule that detects the first occurrence of a specific AWS ARN accessing SecureString parameters with decryption within the last 10 days. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Systems Manager], [Tactic: Credential Access], [Resources: Investigation Guide] |8.9.0 |1 @@ -208,17 +210,17 @@ and their rule type is `machine_learning`. |<> |Detects events that have a mismatch on the expected event agent ID. The status "agent_id_mismatch/mismatch" occurs when the expected agent ID associated with the API key does not match the actual agent ID in an event. This could indicate attempts to spoof events in order to masquerade actual activity to evade detection. |[Use Case: Threat Detection], [Tactic: Defense Evasion] |None |102 -|<> |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. |[Use Case: Threat Detection], [Tactic: Defense Evasion] |None |101 +|<> |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. |[Use Case: Threat Detection], [Tactic: Defense Evasion] |None |102 |<> |Identifies the creation of an Alternate Data Stream (ADS) at a volume root directory, which can indicate the attempt to hide tools and malware, as ADSs created in this directory are not displayed by system utilities. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Data Source: Sysmon] |None |1 -|<> |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. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Resource Development] |None |103 +|<> |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. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Resource Development] |None |104 -|<> |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. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Persistence], [Resources: Investigation Guide] |None |104 +|<> |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. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Persistence], [Resources: Investigation Guide] |None |105 -|<> |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. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Persistence], [Tactic: Execution] |None |105 +|<> |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. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Persistence], [Tactic: Execution] |None |106 -|<> |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. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Persistence], [Resources: Investigation Guide] |None |105 +|<> |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. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Persistence], [Resources: Investigation Guide] |None |106 |<> |Detects execution via the Apple script interpreter (osascript) followed by a network connection from the same process within a short time period. Adversaries may use malicious scripts for execution and command and control. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Command and Control], [Tactic: Execution], [Data Source: Elastic Defend] |None |106 @@ -458,7 +460,9 @@ and their rule type is `machine_learning`. |<> |Identifies the occurrence of a CyberArk Privileged Access Security (PAS) non-error level audit event which is recommended for monitoring by the vendor. The event.code correlates to the CyberArk Vault Audit Action Code. |[Data Source: CyberArk PAS], [Use Case: Log Auditing], [Use Case: Threat Detection], [Tactic: Privilege Escalation] |None |102 -|<> |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. |[Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Command and Control] |None |103 +|<> |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. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Data Source: Sysmon] |None |1 + +|<> |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. |[Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Command and Control] |None |104 |<> |Identifies when a user enables DNS-over-HTTPS. This can be used to hide internet activity or the process of exfiltrating data. With this enabled, an organization will lose visibility into data such as query type, response, and originating IP, which are used to determine bad actors. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon] |None |110 @@ -762,6 +766,8 @@ and their rule type is `machine_learning`. |<> |Detects a high number of unique private repo clone events originating from a single personal access token within a short time period. |[Domain: Cloud], [Use Case: Threat Detection], [Use Case: UEBA], [Tactic: Execution], [Data Source: Github] |None |1 +|<> |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. |[Use Case: Identity and Access Audit], [Data Source: Okta], [Tactic: Credential Access] |8.13.0 |1 + |<> |Identifies a high number of Okta user password reset or account unlock attempts. An adversary may attempt to obtain unauthorized access to Okta user accounts using these methods and attempt to blend in with normal activity in their target's environment and evade detection. |[Use Case: Identity and Access Audit], [Data Source: Okta], [Tactic: Defense Evasion] |8.10.0 |208 |<> |This rule identifies a high number (10) of process terminations via pkill from the same host within a short time period. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Impact], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Auditd Manager] |None |112 @@ -1042,10 +1048,16 @@ and their rule type is `machine_learning`. |<> |Detects when Okta user authentication events are reported for multiple users with the same device token hash behind a proxy. |[Use Case: Identity and Access Audit], [Data Source: Okta], [Tactic: Credential Access] |8.10.0 |2 +|<> |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. |[Use Case: Identity and Access Audit], [Data Source: Okta], [Tactic: Credential Access] |8.13.0 |1 + +|<> |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. |[Use Case: Identity and Access Audit], [Data Source: Okta], [Tactic: Credential Access] |8.13.0 |1 + |<> |Windows Credential Manager allows you to create, view, or delete saved credentials for signing into websites, connected applications, and networks. An adversary may abuse this to list or dump credentials stored in the Credential Manager for saved usernames and passwords. This may also be performed in preparation of lateral movement. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access] |None |10 |<> |This rule helps you test and practice using alerts with Elastic Security as you get set up. It’s not a sign of threat activity. |[Use Case: Guided Onboarding] |None |3 +|<> |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. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Elastic Endgame], [Data Source: Elastic Defend] |None |1 + |<> |Identifies a copy operation of the Active Directory Domain Database (ntds.dit) or Security Account Manager (SAM) files. Those files contain sensitive information including hashed domain and/or local credentials. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Elastic Endgame], [Data Source: Elastic Defend] |None |112 |<> |Identifies suspicious usage of unshare to manipulate system namespaces. Unshare can be utilized to escalate privileges or escape container security boundaries. Threat actors have utilized this binary to allow themselves to escape to the host and access other resources or escalate privileges. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Elastic Endgame], [Data Source: Elastic Defend] |None |9 @@ -1082,7 +1094,7 @@ and their rule type is `machine_learning`. |<> |Identifies the ability of a process to be able to create RAW and PACKET socket types for the available network namespaces by a non-root user. A malicious process with this capability may exploit routing between hosts, bypass network access controls, and otherwise tamper with host networking if a firewall is not in place to limit the packet types and contents. The CAP_NET_RAW capability allows the process to bind to any address within the available namespaces, which allows network traffic sniffing by a non root user. The rule identifies previously unknown processes executing with CAP_NET_RAW capabilities through the use of the new terms rule type. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Discovery], [Data Source: Elastic Defend] |8.11.0 |2 -|<> |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. |[Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning] |None |103 +|<> |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. |[Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning] |None |104 |<> |Identifies the attempt to disable Network-Level Authentication (NLA) via registry modification. Network Level Authentication (NLA) is a feature on Windows that provides an extra layer of security for Remote Desktop (RDP) connections, as it requires users to authenticate before allowing a full RDP session. Attackers can disable NLA to enable persistence methods that require access to the Windows sign-in screen without authenticating, such as Accessibility Features persistence methods, like Sticky Keys. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Data Source: Elastic Endgame] |None |3 @@ -1124,7 +1136,7 @@ and their rule type is `machine_learning`. |<> |A user has initiated a session impersonation granting them access to the environment with the permissions of the user they are impersonating. This would likely indicate Okta administrative access and should only ever occur if requested and expected. |[Use Case: Identity and Access Audit], [Tactic: Credential Access], [Data Source: Okta] |8.10.0 |207 -|<> |Detects when a specific Okta actor has multiple sessions started from different geolocations. |[Use Case: Identity and Access Audit], [Data Source: Okta], [Tactic: Initial Access] |8.10.0 |1 +|<> |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. |[Use Case: Identity and Access Audit], [Data Source: Okta], [Tactic: Initial Access] |8.13.0 |101 |<> |Identifies the occurence of files uploaded to OneDrive being detected as Malware by the file scanning engine. Attackers can use File Sharing and Organization Repositories to spread laterally within the company and amplify their access. Users can inadvertently share these files without knowing their maliciousness, giving adversaries opportunity to gain initial access to other endpoints in the environment. |[Domain: Cloud], [Data Source: Microsoft 365], [Tactic: Lateral Movement] |None |206 @@ -1346,7 +1358,7 @@ and their rule type is `machine_learning`. |<> |Identifies modifications to the Atom desktop text editor Init File. Adversaries may add malicious JavaScript code to the init.coffee file that will be executed upon the Atom application opening. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Elastic Defend] |None |106 -|<> |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. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Privilege Escalation], [Data Source: File Integrity Monitoring] |None |1 +|<> |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. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Privilege Escalation], [Data Source: File Integrity Monitoring] |None |2 |<> |Identifies the creation or modification of the login window property list (plist). Adversaries may modify plist files to run a program during system boot or user login for persistence. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Persistence], [Data Source: Elastic Defend] |None |108 @@ -1386,6 +1398,8 @@ and their rule type is `machine_learning`. |<> |This rule monitors a sequence involving a program compilation event followed by its execution and a subsequent alteration of UID permissions to root privileges. This behavior can potentially indicate the execution of a kernel or software privilege escalation exploit. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Use Case: Vulnerability], [Data Source: Elastic Defend] |None |4 +|<> |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. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Tactic: Privilege Escalation], [Data Source: Elastic Defend], [Data Source: Sysmon] |None |1 + |<> |A sudoers file specifies the commands users or groups can run and from which terminals. Adversaries can take advantage of these configurations to execute commands as other users or spawn processes with higher privileges. |[Domain: Endpoint], [OS: Linux], [OS: macOS], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Elastic Defend] |None |103 |<> |This rule monitors for the execution of the systemd-run command by a user with a UID that is larger than the maximum allowed UID size (INT_MAX). Some older Linux versions were affected by a bug which allows user accounts with a UID greater than INT_MAX to escalate privileges by spawning a shell through systemd-run. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Elastic Defend], [Data Source: Elastic Endgame] |None |5 @@ -1472,6 +1486,8 @@ and their rule type is `machine_learning`. |<> |Identifies commands that can access and decrypt Veeam credentials stored in MSSQL databases. Attackers can use Veeam Credentials to target backups as part of destructive operations such as Ransomware attacks. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Credential Access], [Data Source: Elastic Endgame], [Data Source: Elastic Defend] |None |1 +|<> |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. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Data Source: Active Directory], [Use Case: Active Directory Monitoring] |None |1 + |<> |This rule uses alert data to determine when a malware signature is triggered in multiple hosts. Analysts can use this to prioritize triage and response, as this can potentially indicate a widespread malware infection. |[Domain: Endpoint], [Data Source: Elastic Defend], [Use Case: Threat Detection], [Tactic: Execution], [Rule Type: Higher-Order Rule] |8.13.0 |1 |<> |Identifies suspicious instances of the Windows Error Reporting process (WerFault.exe or Wermgr.exe) with matching command-line and process executable values performing outgoing network connections. This may be indicative of a masquerading attempt to evade suspicious child process behavior detections. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Sysmon] |None |108 @@ -1612,11 +1628,13 @@ and their rule type is `machine_learning`. |<> |This rule attempts to identify rapid secret retrieval attempts from AWS SecretsManager. Adversaries may attempt to retrieve secrets from the Secrets Manager programmatically using the `GetSecretValue` or `BatchGetSecretValue` API actions. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Data Source: AWS Secrets Manager], [Tactic: Credential Access], [Resources: Investigation Guide] |8.9.0 |1 -|<> |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. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Rule Type: ML], [Rule Type: Machine Learning], [Resources: Investigation Guide] |None |208 +|<> |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. |[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] |None |1 + +|<> |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. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Rule Type: ML], [Rule Type: Machine Learning], [Resources: Investigation Guide] |None |209 |<> |This rule detects rare internet network connections via the SMB protocol. SMB is commonly used to leak NTLM credentials via rogue UNC path injection. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Exfiltration], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon] |None |3 -|<> |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. |[Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Initial Access], [Resources: Investigation Guide] |None |104 +|<> |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. |[Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Initial Access], [Resources: Investigation Guide] |None |105 |<> |Detects attempts to maintain persistence by creating registry keys using AppCert DLLs. AppCert DLLs are loaded by every process using the common API functions to create processes. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Privilege Escalation], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: SentinelOne] |8.13.0 |310 @@ -1746,21 +1764,21 @@ and their rule type is `machine_learning`. |<> |Identifies a SolarWinds binary modifying the start type of a service to be disabled. An adversary may abuse this technique to manipulate relevant security services. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Initial Access], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon] |None |110 -|<> |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. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Rule Type: ML], [Rule Type: Machine Learning], [Resources: Investigation Guide] |None |208 +|<> |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. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Rule Type: ML], [Rule Type: Machine Learning], [Resources: Investigation Guide] |None |209 |<> |A machine learning job has detected high bytes of data written to an external device. In a typical operational setting, there is usually a predictable pattern or a certain range of data that is written to external devices. An unusually large amount of data being written is anomalous and can signal illicit data copying or transfer activities. |[Use Case: Data Exfiltration Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Exfiltration] |None |4 |<> |A machine learning job has detected high bytes of data written to an external device via Airdrop. In a typical operational setting, there is usually a predictable pattern or a certain range of data that is written to external devices. An unusually large amount of data being written is anomalous and can signal illicit data copying or transfer activities. |[Use Case: Data Exfiltration Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Exfiltration] |None |4 -|<> |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. |[Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Credential Access], [Resources: Investigation Guide] |None |104 +|<> |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. |[Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Credential Access], [Resources: Investigation Guide] |None |105 -|<> |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. |[Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning] |None |103 +|<> |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. |[Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning] |None |104 -|<> |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. |[Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Credential Access] |None |103 +|<> |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. |[Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Credential Access] |None |104 -|<> |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. |[Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning] |None |103 +|<> |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. |[Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning] |None |104 -|<> |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. |[Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning] |None |104 +|<> |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. |[Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning] |None |105 |<> |A machine learning job has detected a high count of destination IPs establishing an RDP connection with a single source IP. Once an attacker has gained access to one system, they might attempt to access more in the network in search of valuable assets, data, or further access points. |[Use Case: Lateral Movement Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Lateral Movement] |None |4 @@ -1770,7 +1788,7 @@ and their rule type is `machine_learning`. |<> |A machine learning job has detected an abnormal volume of remote files shared on the host indicating potential lateral movement activity. One of the primary goals of attackers after gaining access to a network is to locate and exfiltrate valuable information. Attackers might perform multiple small transfers to match normal egress activity in the network, to evade detection. |[Use Case: Lateral Movement Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Lateral Movement] |None |4 -|<> |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. |[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] |None |104 +|<> |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. |[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] |None |105 |<> |Identifies files written or modified in the startup folder by unsigned processes. Adversaries may abuse this technique to maintain persistence in an environment. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Defense Evasion], [Resources: Investigation Guide], [Data Source: Elastic Defend] |None |109 @@ -1918,7 +1936,7 @@ and their rule type is `machine_learning`. |<> |Identifies the PowerShell engine being invoked by unexpected processes. Rather than executing PowerShell functionality with powershell.exe, some attackers do this to operate more stealthily. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Resources: Investigation Guide], [Data Source: Elastic Defend] |None |210 -|<> |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. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Execution] |None |104 +|<> |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. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Execution] |None |105 |<> |Detects deletion of print driver files by an unusual process. This may indicate a clean up attempt post successful privilege escalation via Print Spooler service related vulnerabilities. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Elastic Endgame], [Use Case: Vulnerability], [Data Source: Elastic Defend], [Data Source: Sysmon] |None |107 @@ -2032,13 +2050,13 @@ and their rule type is `machine_learning`. |<> |Identifies the deletion of backup files, saved using third-party software, by a process outside of the backup suite. Adversaries may delete Backup files to ensure that recovery from a ransomware attack is less likely. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Impact], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend] |None |113 -|<> |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. |[OS: Windows], [Data Source: Elastic Endgame], [Rule Type: Indicator Match] |None |7 +|<> |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. |[OS: Windows], [Data Source: Elastic Endgame], [Rule Type: Threat Match] |None |8 -|<> |This rule is triggered when an IP address indicator from the Threat Intel Filebeat module or integrations has a match against a network event. |[OS: Windows], [Data Source: Elastic Endgame], [Rule Type: Indicator Match] |None |6 +|<> |This rule is triggered when an IP address indicator from the Threat Intel Filebeat module or integrations has a match against a network event. |[OS: Windows], [Data Source: Elastic Endgame], [Rule Type: Threat Match] |None |7 -|<> |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. |[OS: Windows], [Data Source: Elastic Endgame], [Rule Type: Indicator Match] |None |6 +|<> |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. |[OS: Windows], [Data Source: Elastic Endgame], [Rule Type: Threat Match] |None |7 -|<> |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. |[OS: Windows], [Data Source: Elastic Endgame], [Rule Type: Indicator Match] |None |6 +|<> |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. |[OS: Windows], [Data Source: Elastic Endgame], [Rule Type: Threat Match] |None |7 |<> |Timestomping is an anti-forensics technique which is used to modify the timestamps of a file, often to mimic files that are in the same folder. |[Domain: Endpoint], [OS: Linux], [OS: macOS], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Defend] |None |106 @@ -2078,9 +2096,11 @@ and their rule type is `machine_learning`. |<> |Identifies a Windows trusted program running from locations often abused by adversaries to masquerade as a trusted program and loading a recently dropped DLL. This behavior may indicate an attempt to evade defenses via side-loading a malicious DLL within the memory space of a signed processes. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Defend] |None |8 +|<> |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. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Privilege Escalation], [Data Source: Elastic Defend], [Data Source: Sysmon] |None |1 + |<> |Identifies attempt to load an untrusted driver. Adversaries may modify code signing policies to enable execution of unsigned or self-signed code. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Resources: Investigation Guide], [Data Source: Elastic Defend] |None |9 -|<> |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. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Rule Type: ML], [Rule Type: Machine Learning], [Resources: Investigation Guide] |None |208 +|<> |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. |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Rule Type: ML], [Rule Type: Machine Learning], [Resources: Investigation Guide] |None |209 |<> |Identifies a suspicious child process of the Windows virtual system process, which could indicate code injection. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Endgame], [Data Source: Elastic Defend] |None |110 @@ -2088,11 +2108,11 @@ and their rule type is `machine_learning`. |<> |Identifies child processes of unusual instances of RunDLL32 where the command line parameters were suspicious. Misuse of RunDLL32 could indicate malicious activity. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Defend], [Data Source: Sysmon] |None |108 -|<> |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). |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Rule Type: ML], [Rule Type: Machine Learning], [Resources: Investigation Guide] |None |208 +|<> |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). |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Rule Type: ML], [Rule Type: Machine Learning], [Resources: Investigation Guide] |None |209 -|<> |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). |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Rule Type: ML], [Rule Type: Machine Learning], [Resources: Investigation Guide] |None |208 +|<> |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). |[Domain: Cloud], [Data Source: AWS], [Data Source: Amazon Web Services], [Rule Type: ML], [Rule Type: Machine Learning], [Resources: Investigation Guide] |None |209 -|<> |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. |[Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Command and Control] |None |103 +|<> |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. |[Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Command and Control] |None |104 |<> |This rule leverages alert data from various Discovery building block rules to alert on signals with unusual unique host.id and user.id entries. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Discovery], [Rule Type: Higher-Order Rule] |None |1 @@ -2110,29 +2130,29 @@ and their rule type is `machine_learning`. |<> |Detects repeated high-confidence 'BLOCKED' actions coupled with specific violation codes such as 'MISCONDUCT', indicating persistent misuse or attempts to probe the model's ethical boundaries. |[Domain: LLM], [Data Source: AWS Bedrock], [Data Source: AWS S3], [Use Case: Policy Violation], [Mitre Atlas: T0051], [Mitre Atlas: T0054] |8.13.0 |1 -|<> |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. |[Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Initial Access], [Resources: Investigation Guide] |None |104 +|<> |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. |[Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Initial Access], [Resources: Investigation Guide] |None |105 -|<> |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. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning] |None |103 +|<> |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. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning] |None |104 -|<> |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. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Discovery] |None |104 +|<> |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. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Discovery] |None |105 -|<> |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. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Discovery] |None |103 +|<> |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. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Discovery] |None |104 -|<> |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. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning] |None |103 +|<> |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. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning] |None |104 -|<> |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. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Credential Access] |None |103 +|<> |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. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Credential Access] |None |104 -|<> |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. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Discovery] |None |103 +|<> |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. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Discovery] |None |104 -|<> |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. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Discovery] |None |103 +|<> |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. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Discovery] |None |104 -|<> |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. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Credential Access] |None |103 +|<> |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. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Credential Access] |None |104 -|<> |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. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Discovery] |None |104 +|<> |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. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Discovery] |None |105 -|<> |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. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Initial Access] |None |103 +|<> |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. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Initial Access] |None |104 -|<> |Identifies an unusually high number of authentication attempts. |[Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Credential Access] |None |103 +|<> |Identifies an unusually high number of authentication attempts. |[Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Credential Access] |None |104 |<> |Identifies network activity from unexpected system applications. This may indicate adversarial activity as these applications are often leveraged by adversaries to execute code and evade detection. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Sysmon] |None |112 @@ -2140,7 +2160,7 @@ and their rule type is `machine_learning`. |<> |Identifies unusual instances of rundll32.exe making outbound network connections. This may indicate adversarial Command and Control activity. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Command and Control], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Sysmon] |None |109 -|<> |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. |[Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning] |None |103 +|<> |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. |[Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning] |None |104 |<> |Identifies a suspicious parent child process relationship with cmd.exe descending from an unusual process. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon], [Data Source: SentinelOne] |8.13.0 |312 @@ -2158,9 +2178,9 @@ and their rule type is `machine_learning`. |<> |Identifies unusual process executions using MSSQL Service accounts, which can indicate the exploitation/compromise of SQL instances. Attackers may exploit exposed MSSQL instances for initial access or lateral movement. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Lateral Movement], [Tactic: Persistence], [Data Source: Elastic Defend], [Rule Type: BBR] |None |4 -|<> |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. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Persistence] |None |104 +|<> |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. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Persistence] |None |105 -|<> |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. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Persistence], [Resources: Investigation Guide] |None |108 +|<> |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. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Persistence], [Resources: Investigation Guide] |None |109 |<> |Identifies network activity from unexpected system applications. This may indicate adversarial activity as these applications are often leveraged by adversaries to execute code and evade detection. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Resources: Investigation Guide], [Data Source: Elastic Defend], [Data Source: Sysmon] |None |108 @@ -2180,33 +2200,33 @@ and their rule type is `machine_learning`. |<> |Identifies unusual child processes of Service Host (svchost.exe) that traditionally do not spawn any child processes. This may indicate a code injection or an equivalent form of exploitation. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Tactic: Privilege Escalation], [Data Source: Elastic Endgame], [Data Source: Elastic Defend], [Data Source: Sysmon] |None |110 -|<> |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. |[Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Initial Access] |None |103 +|<> |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. |[Use Case: Identity and Access Audit], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Initial Access] |None |104 -|<> |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. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Privilege Escalation] |None |103 +|<> |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. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Privilege Escalation] |None |104 |<> |A machine learning job has detected an RDP session started at an usual time or weekday. An RDP session at an unusual time could be followed by other suspicious activities, so catching this is a good first step in detecting a larger attack. |[Use Case: Lateral Movement Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Lateral Movement] |None |4 |<> |This rule monitors for a sequence of 20 "id" command executions within 1 second by the same parent process. This behavior is unusual, and may be indicative of the execution of an enumeration script such as LinPEAS or LinEnum. These scripts leverage the "id" command to enumerate the privileges of all users present on the system. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Discovery], [Data Source: Elastic Defend] |None |4 -|<> |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. |[Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Command and Control] |None |103 +|<> |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. |[Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Command and Control] |None |104 -|<> |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. |[Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Command and Control] |None |103 +|<> |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. |[Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Command and Control] |None |104 -|<> |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. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning] |None |103 +|<> |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. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning] |None |104 -|<> |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. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Persistence], [Tactic: Execution] |None |104 +|<> |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. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Persistence], [Tactic: Execution] |None |105 -|<> |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. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Credential Access] |None |103 +|<> |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. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Credential Access] |None |104 -|<> |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. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Initial Access] |None |103 +|<> |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. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Initial Access] |None |104 -|<> |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. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Persistence] |None |103 +|<> |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. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Persistence] |None |104 -|<> |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. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Credential Access] |None |103 +|<> |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. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Credential Access] |None |104 -|<> |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. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Privilege Escalation] |None |103 +|<> |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. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Privilege Escalation] |None |104 -|<> |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. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Initial Access] |None |104 +|<> |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. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Rule Type: ML], [Rule Type: Machine Learning], [Tactic: Initial Access] |None |105 |<> |Identifies attempts to create new users. This is sometimes done by attackers to increase access or establish persistence on a system or domain. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Persistence], [Resources: Investigation Guide], [Data Source: Elastic Endgame], [Data Source: Elastic Defend] |None |109 @@ -2298,6 +2318,10 @@ and their rule type is `machine_learning`. |<> |Identifies attempts to dump Wireless saved access keys in clear text using the Windows built-in utility Netsh. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Credential Access], [Tactic: Discovery], [Data Source: Elastic Endgame], [Resources: Investigation Guide], [Data Source: Elastic Defend] |None |8 +|<> |Detects file creation events in the plugin directories for the Yum package manager. In Linux, Yum (Yellowdog Updater, Modified) is a command-line utility used for handling packages on (by default) Fedora-based systems, providing functions for installing, updating, upgrading, and removing software along with managing package repositories. Attackers can backdoor Yum to gain persistence by injecting malicious code into plugins that Yum runs, thereby ensuring continued unauthorized access or control each time Yum is used for package management. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Persistence], [Tactic: Defense Evasion], [Data Source: Elastic Defend] |None |1 + +|<> |This rule detects the execution of the `grep` command with the `plugins` argument on Linux systems. This command is used to search for YUM/DNF configurations and/or plugins with an enabled state. This behavior may indicate an attacker is attempting to establish persistence in a YUM or DNF plugin. |[Domain: Endpoint], [OS: Linux], [Use Case: Threat Detection], [Tactic: Discovery], [Data Source: Elastic Defend], [Data Source: Elastic Endgame] |None |1 + |<> |This rule identifies Zoom meetings that are created without a passcode. Meetings without a passcode are susceptible to Zoombombing. Zoombombing is carried out by taking advantage of Zoom sessions that are not protected with a passcode. Zoombombing refers to the unwanted, disruptive intrusion, generally by Internet trolls and hackers, into a video conference call. In a typical Zoombombing incident, a teleconferencing session is hijacked by the insertion of material that is lewd, obscene, racist, or antisemitic in nature, typically resulting of the shutdown of the session. |[Data Source: Zoom], [Use Case: Configuration Audit], [Tactic: Initial Access] |None |103 |============================================== diff --git a/docs/detections/prebuilt-rules/rule-desc-index.asciidoc b/docs/detections/prebuilt-rules/rule-desc-index.asciidoc index 5e60e92b30..99bb8244f3 100644 --- a/docs/detections/prebuilt-rules/rule-desc-index.asciidoc +++ b/docs/detections/prebuilt-rules/rule-desc-index.asciidoc @@ -43,6 +43,7 @@ include::rule-details/aws-iam-password-recovery-requested.asciidoc[] include::rule-details/aws-iam-roles-anywhere-profile-creation.asciidoc[] include::rule-details/aws-iam-roles-anywhere-trust-anchor-created-with-external-ca.asciidoc[] include::rule-details/aws-iam-user-addition-to-group.asciidoc[] +include::rule-details/aws-iam-user-created-access-keys-for-another-user.asciidoc[] include::rule-details/aws-kms-customer-managed-key-disabled-or-scheduled-for-deletion.asciidoc[] include::rule-details/aws-lambda-function-created-or-updated.asciidoc[] include::rule-details/aws-lambda-function-policy-updated-to-allow-public-invocation.asciidoc[] @@ -220,6 +221,7 @@ include::rule-details/credential-manipulation-prevented-elastic-endgame.asciidoc include::rule-details/cron-job-created-or-modified.asciidoc[] include::rule-details/cyberark-privileged-access-security-error.asciidoc[] include::rule-details/cyberark-privileged-access-security-recommended-monitor.asciidoc[] +include::rule-details/dns-global-query-block-list-modified-or-disabled.asciidoc[] include::rule-details/dns-tunneling.asciidoc[] include::rule-details/dns-over-https-enabled-via-registry.asciidoc[] include::rule-details/default-cobalt-strike-team-server-certificate.asciidoc[] @@ -372,6 +374,7 @@ include::rule-details/hidden-files-and-directories-via-hidden-flag.asciidoc[] include::rule-details/high-mean-of-process-arguments-in-an-rdp-session.asciidoc[] include::rule-details/high-mean-of-rdp-session-duration.asciidoc[] include::rule-details/high-number-of-cloned-github-repos-from-pat.asciidoc[] +include::rule-details/high-number-of-okta-device-token-cookies-generated-for-authentication.asciidoc[] include::rule-details/high-number-of-okta-user-password-reset-or-unlock-attempts.asciidoc[] include::rule-details/high-number-of-process-terminations.asciidoc[] include::rule-details/high-number-of-process-and-or-service-terminations.asciidoc[] @@ -512,8 +515,11 @@ include::rule-details/multiple-logon-failure-from-the-same-source-address.asciid include::rule-details/multiple-okta-client-addresses-for-a-single-user-session.asciidoc[] include::rule-details/multiple-okta-sessions-detected-for-a-single-user.asciidoc[] include::rule-details/multiple-okta-user-auth-events-with-same-device-token-hash-behind-a-proxy.asciidoc[] +include::rule-details/multiple-okta-user-authentication-events-with-client-address.asciidoc[] +include::rule-details/multiple-okta-user-authentication-events-with-same-device-token-hash.asciidoc[] include::rule-details/multiple-vault-web-credentials-read.asciidoc[] include::rule-details/my-first-rule.asciidoc[] +include::rule-details/ntds-dump-via-wbadmin.asciidoc[] include::rule-details/ntds-or-sam-database-file-copied.asciidoc[] include::rule-details/namespace-manipulation-using-unshare.asciidoc[] include::rule-details/netcat-listener-established-inside-a-container.asciidoc[] @@ -684,6 +690,7 @@ include::rule-details/potential-privilege-escalation-via-overlayfs.asciidoc[] include::rule-details/potential-privilege-escalation-via-pkexec.asciidoc[] include::rule-details/potential-privilege-escalation-via-python-cap-setuid.asciidoc[] include::rule-details/potential-privilege-escalation-via-recently-compiled-executable.asciidoc[] +include::rule-details/potential-privilege-escalation-via-service-imagepath-modification.asciidoc[] include::rule-details/potential-privilege-escalation-via-sudoers-file-modification.asciidoc[] include::rule-details/potential-privilege-escalation-via-uid-int-max-bug-detected.asciidoc[] include::rule-details/potential-privileged-escalation-via-samaccountname-spoofing.asciidoc[] @@ -727,6 +734,7 @@ include::rule-details/potential-suspicious-file-edit.asciidoc[] include::rule-details/potential-unauthorized-access-via-wildcard-injection-detected.asciidoc[] include::rule-details/potential-upgrade-of-non-interactive-shell.asciidoc[] include::rule-details/potential-veeam-credential-access-command.asciidoc[] +include::rule-details/potential-wpad-spoofing-via-dns-record-creation.asciidoc[] include::rule-details/potential-widespread-malware-infection-across-multiple-hosts.asciidoc[] include::rule-details/potential-windows-error-manager-masquerading.asciidoc[] include::rule-details/potential-windows-session-hijacking-via-ccmexec.asciidoc[] @@ -797,6 +805,7 @@ include::rule-details/rpc-remote-procedure-call-to-the-internet.asciidoc[] include::rule-details/ransomware-detected-elastic-endgame.asciidoc[] include::rule-details/ransomware-prevented-elastic-endgame.asciidoc[] include::rule-details/rapid-secret-retrieval-attempts-from-aws-secretsmanager.asciidoc[] +include::rule-details/rapid7-threat-command-cves-correlation.asciidoc[] include::rule-details/rare-aws-error-code.asciidoc[] include::rule-details/rare-smb-connection-to-the-internet.asciidoc[] include::rule-details/rare-user-logon.asciidoc[] @@ -1030,6 +1039,7 @@ include::rule-details/unsigned-bits-service-client-process.asciidoc[] include::rule-details/unsigned-dll-loaded-by-svchost.asciidoc[] include::rule-details/unsigned-dll-loaded-by-a-trusted-process.asciidoc[] include::rule-details/unsigned-dll-side-loading-from-a-suspicious-folder.asciidoc[] +include::rule-details/unsigned-dll-loaded-by-dns-service.asciidoc[] include::rule-details/untrusted-driver-loaded.asciidoc[] include::rule-details/unusual-aws-command-for-a-user.asciidoc[] include::rule-details/unusual-child-process-from-a-system-virtual-process.asciidoc[] @@ -1140,4 +1150,6 @@ include::rule-details/windows-system-information-discovery.asciidoc[] include::rule-details/windows-system-network-connections-discovery.asciidoc[] include::rule-details/windows-user-account-creation.asciidoc[] include::rule-details/wireless-credential-dumping-using-netsh-command.asciidoc[] +include::rule-details/yum-package-manager-plugin-file-creation.asciidoc[] +include::rule-details/yum-dnf-plugin-status-discovery.asciidoc[] include::rule-details/zoom-meeting-with-no-passcode.asciidoc[] \ No newline at end of file diff --git a/docs/detections/prebuilt-rules/rule-details/agent-spoofing-multiple-hosts-using-same-agent.asciidoc b/docs/detections/prebuilt-rules/rule-details/agent-spoofing-multiple-hosts-using-same-agent.asciidoc index 519b95923d..d35bf536a9 100644 --- a/docs/detections/prebuilt-rules/rule-details/agent-spoofing-multiple-hosts-using-same-agent.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/agent-spoofing-multiple-hosts-using-same-agent.asciidoc @@ -28,7 +28,7 @@ Detects when multiple hosts are using the same agent ID. This could occur in the * Use Case: Threat Detection * Tactic: Defense Evasion -*Version*: 101 +*Version*: 102 *Rule authors*: @@ -42,7 +42,7 @@ Detects when multiple hosts are using the same agent ID. This could occur in the [source, js] ---------------------------------- -event.agent_id_status:* +event.agent_id_status:* and not tags:forwarded ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/anomalous-linux-compiler-activity.asciidoc b/docs/detections/prebuilt-rules/rule-details/anomalous-linux-compiler-activity.asciidoc index 0dd52130b1..7364f9fef6 100644 --- a/docs/detections/prebuilt-rules/rule-details/anomalous-linux-compiler-activity.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/anomalous-linux-compiler-activity.asciidoc @@ -28,7 +28,7 @@ Looks for compiler activity by a user context which does not normally run compil * Rule Type: Machine Learning * Tactic: Resource Development -*Version*: 103 +*Version*: 104 *Rule authors*: @@ -37,6 +37,76 @@ Looks for compiler activity by a user context which does not normally run compil *Rule license*: Elastic License v2 +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Auditd Manager + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditd Manager Integration Setup* + +The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel. +Auditd 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. + + +*The following steps should be executed in order to add the Elastic Agent System integration "auditd_manager" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Auditd Manager” and select the integration to see more details about it. +- Click “Add Auditd Manager”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “auditd manager” to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/auditd_manager[helper guide]. + + +*Rule Specific Setup Note* + +Auditd Manager subscribes to the kernel and receives events as they occur without any additional configuration. +However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from. +- For this detection rule no additional audit rules are required. + + *Framework*: MITRE ATT&CK^TM^ * Tactic: diff --git a/docs/detections/prebuilt-rules/rule-details/anomalous-process-for-a-linux-population.asciidoc b/docs/detections/prebuilt-rules/rule-details/anomalous-process-for-a-linux-population.asciidoc index 8799f4758f..9c2595d292 100644 --- a/docs/detections/prebuilt-rules/rule-details/anomalous-process-for-a-linux-population.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/anomalous-process-for-a-linux-population.asciidoc @@ -31,7 +31,7 @@ Searches for rare processes running on multiple Linux hosts in an entire fleet o * Tactic: Persistence * Resources: Investigation Guide -*Version*: 104 +*Version*: 105 *Rule authors*: @@ -91,6 +91,76 @@ This rule uses a machine learning job to detect a Linux process that is rare and - 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). +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Auditd Manager + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditd Manager Integration Setup* + +The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel. +Auditd 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. + + +*The following steps should be executed in order to add the Elastic Agent System integration "auditd_manager" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Auditd Manager” and select the integration to see more details about it. +- Click “Add Auditd Manager”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “auditd manager” to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/auditd_manager[helper guide]. + + +*Rule Specific Setup Note* + +Auditd Manager subscribes to the kernel and receives events as they occur without any additional configuration. +However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from. +- For this detection rule no additional audit rules are required. + + *Framework*: MITRE ATT&CK^TM^ * Tactic: diff --git a/docs/detections/prebuilt-rules/rule-details/anomalous-process-for-a-windows-population.asciidoc b/docs/detections/prebuilt-rules/rule-details/anomalous-process-for-a-windows-population.asciidoc index 8c0a537aa3..3ad5914bd8 100644 --- a/docs/detections/prebuilt-rules/rule-details/anomalous-process-for-a-windows-population.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/anomalous-process-for-a-windows-population.asciidoc @@ -31,7 +31,7 @@ Searches for rare processes running on multiple hosts in an entire fleet or netw * Tactic: Persistence * Tactic: Execution -*Version*: 105 +*Version*: 106 *Rule authors*: @@ -117,6 +117,68 @@ This rule uses a machine learning job to detect a Windows process that is rare a - 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). +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Windows + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Windows Integration Setup* + +The Windows integration allows you to monitor the Windows OS, services, applications, and more. + + +*The following steps should be executed in order to add the Elastic Agent System integration "windows" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Windows” and select the integration to see more details about it. +- Click “Add Windows”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “windows” to an existing or a new agent policy, and deploy the agent on your system from which windows log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/windows[helper guide]. + + *Framework*: MITRE ATT&CK^TM^ * Tactic: diff --git a/docs/detections/prebuilt-rules/rule-details/anomalous-windows-process-creation.asciidoc b/docs/detections/prebuilt-rules/rule-details/anomalous-windows-process-creation.asciidoc index 9fc581fe54..0eec9902a9 100644 --- a/docs/detections/prebuilt-rules/rule-details/anomalous-windows-process-creation.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/anomalous-windows-process-creation.asciidoc @@ -31,7 +31,7 @@ Identifies unusual parent-child process relationships that can indicate malware * Tactic: Persistence * Resources: Investigation Guide -*Version*: 105 +*Version*: 106 *Rule authors*: @@ -117,6 +117,68 @@ This rule uses a machine learning job to detect an anomalous Windows process wit - 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). +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Windows + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Windows Integration Setup* + +The Windows integration allows you to monitor the Windows OS, services, applications, and more. + + +*The following steps should be executed in order to add the Elastic Agent System integration "windows" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Windows” and select the integration to see more details about it. +- Click “Add Windows”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “windows” to an existing or a new agent policy, and deploy the agent on your system from which windows log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/windows[helper guide]. + + *Framework*: MITRE ATT&CK^TM^ * Tactic: diff --git a/docs/detections/prebuilt-rules/rule-details/aws-iam-user-created-access-keys-for-another-user.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-iam-user-created-access-keys-for-another-user.asciidoc new file mode 100644 index 0000000000..11469a2b6f --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/aws-iam-user-created-access-keys-for-another-user.asciidoc @@ -0,0 +1,149 @@ +[[aws-iam-user-created-access-keys-for-another-user]] +=== AWS IAM User Created Access Keys For Another User + +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. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-10m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*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 + +*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 + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating AWS IAM User Created Access Keys For Another User* + + +AWS access keys created for IAM users or root user are long-term credentials that provide programatic access to AWS. +With access to the `iam:CreateAccessKey` permission, a set of compromised credentials could be used to create a new +set of credentials for another user for privilege escalation or as a means of persistence. This rule uses https://www.elastic.co/guide/en/security/master/rules-ui-create.html#create-esql-rule[ES|QL] +to look for use of the `CreateAccessKey` operation where the user.name is different from the user.target.name. + + + +*Possible investigation steps* + + +- Identify both related accounts and their role in the environment. +- Review IAM permission policies for the user identities. +- Identify the applications or users that should use these accounts. +- Investigate other alerts associated with the accounts during the past 48 hours. +- 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. +- Contact the account owners and confirm whether they are aware of this activity. +- Considering the source IP address and geolocation of the user who issued the command: + - Do they look normal for the calling user? + - 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? + - 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? +- 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. + - Determine what other API calls were made by the user. + - Assess whether this behavior is prevalent in the environment by looking for similar occurrences involving other users. + + +*False positive analysis* + + +- 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. + + +*Response and remediation* + + +- Initiate the incident response process based on the outcome of the triage. +- Disable or limit the account during the investigation and response. + - Rotate user credentials + - Remove the newly created credentials from the affected user(s) +- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context: + - Identify the account role in the cloud environment. + - Assess the criticality of affected services and servers. + - Work with your IT team to identify and minimize the impact on users. + - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. + - Identify any regulatory or legal ramifications related to this activity. +- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. + - Rotate secrets 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. +- Remove unauthorized new accounts, and request password resets for other IAM users. +- Consider enabling multi-factor authentication for users. +- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. +- Implement security best practices https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/[outlined] by AWS. +- Take the actions needed to return affected systems, data, or services to their normal operational levels. +- Identify the initial vector abused by the attacker and take action to prevent reinfection via the same vector. +- 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). + + +==== Rule query + + +[source, js] +---------------------------------- +from logs-aws.cloudtrail-* +| where event.provider == "iam.amazonaws.com" and event.action == "CreateAccessKey" and event.outcome == "success" and user.name != user.target.name + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Credentials +** ID: T1098.001 +** Reference URL: https://attack.mitre.org/techniques/T1098/001/ +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Account Manipulation +** ID: T1098 +** Reference URL: https://attack.mitre.org/techniques/T1098/ +* Sub-technique: +** Name: Additional Cloud Credentials +** ID: T1098.001 +** Reference URL: https://attack.mitre.org/techniques/T1098/001/ diff --git a/docs/detections/prebuilt-rules/rule-details/aws-security-token-service-sts-assumerole-usage.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-security-token-service-sts-assumerole-usage.asciidoc index 26946a1974..8727c3f3a5 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-security-token-service-sts-assumerole-usage.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-security-token-service-sts-assumerole-usage.asciidoc @@ -33,7 +33,7 @@ Identifies the use of AssumeRole. AssumeRole returns a set of temporary security * Use Case: Identity and Access Audit * Tactic: Privilege Escalation -*Version*: 206 +*Version*: 207 *Rule authors*: @@ -57,7 +57,7 @@ The AWS Fleet integration, Filebeat module, or similarly structured data is requ [source, js] ---------------------------------- -event.dataset:aws.cloudtrail and event.provider:sts.amazonaws.com and event.action:AssumedRole and +event.dataset:aws.cloudtrail and event.provider:sts.amazonaws.com and event.action:AssumeRole and aws.cloudtrail.user_identity.session_context.session_issuer.type:Role and event.outcome:success ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/dns-global-query-block-list-modified-or-disabled.asciidoc b/docs/detections/prebuilt-rules/rule-details/dns-global-query-block-list-modified-or-disabled.asciidoc new file mode 100644 index 0000000000..a656884337 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/dns-global-query-block-list-modified-or-disabled.asciidoc @@ -0,0 +1,81 @@ +[[dns-global-query-block-list-modified-or-disabled]] +=== DNS Global Query Block List Modified or Disabled + +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. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.registry-* +* logs-windows.sysmon_operational-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*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/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Defense Evasion +* Data Source: Elastic Defend +* Data Source: Sysmon + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type : "change" and +( + (registry.value : "EnableGlobalQueryBlockList" and registry.data.strings : ("0", "0x00000000")) or + (registry.value : "GlobalQueryBlockList" and not registry.data.strings : "wpad") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Impair Defenses +** ID: T1562 +** Reference URL: https://attack.mitre.org/techniques/T1562/ +* Sub-technique: +** Name: Disable or Modify Tools +** ID: T1562.001 +** Reference URL: https://attack.mitre.org/techniques/T1562/001/ +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Adversary-in-the-Middle +** ID: T1557 +** Reference URL: https://attack.mitre.org/techniques/T1557/ diff --git a/docs/detections/prebuilt-rules/rule-details/dns-tunneling.asciidoc b/docs/detections/prebuilt-rules/rule-details/dns-tunneling.asciidoc index 0aee1969bf..2852bd5da0 100644 --- a/docs/detections/prebuilt-rules/rule-details/dns-tunneling.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/dns-tunneling.asciidoc @@ -28,7 +28,7 @@ A machine learning job detected unusually large numbers of DNS queries for a sin * Rule Type: Machine Learning * Tactic: Command and Control -*Version*: 103 +*Version*: 104 *Rule authors*: @@ -37,6 +37,68 @@ A machine learning job detected unusually large numbers of DNS queries for a sin *Rule license*: Elastic License v2 +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Network Packet Capture + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Network Packet Capture Integration Setup* + +The 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 — 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. + + +*The following steps should be executed in order to add the Elastic Agent System integration "network_traffic" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Network Packet Capture” and select the integration to see more details about it. +- Click “Add Network Packet Capture”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “network_traffic” to an existing or a new agent policy, and deploy the agent on your system from which network log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/network_traffic[helper guide]. + + *Framework*: MITRE ATT&CK^TM^ * Tactic: diff --git a/docs/detections/prebuilt-rules/rule-details/high-number-of-okta-device-token-cookies-generated-for-authentication.asciidoc b/docs/detections/prebuilt-rules/rule-details/high-number-of-okta-device-token-cookies-generated-for-authentication.asciidoc new file mode 100644 index 0000000000..1b6faeddda --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/high-number-of-okta-device-token-cookies-generated-for-authentication.asciidoc @@ -0,0 +1,152 @@ +[[high-number-of-okta-device-token-cookies-generated-for-authentication]] +=== High Number of Okta Device Token Cookies Generated for Authentication + +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. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*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/ + +*Tags*: + +* Use Case: Identity and Access Audit +* Data Source: Okta +* Tactic: Credential Access + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating High Number of Okta Device Token Cookies Generated for Authentication* + + +This 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. + + +*Possible investigation steps:* + +- 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. +- 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. +- 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. +- Review the `okta.security_context.is_proxy` field to determine if the device is a proxy. + - If the device is a proxy, this may indicate that a user is using a proxy to access multiple accounts for password spraying. +- With the list of `okta.actor.alternate_id` values, review `event.outcome` results to determine if the authentication was successful. + - If the authentication was successful for any user, pivoting to `event.action` values for those users may provide additional context. +- With Okta end users identified, review the `okta.debug_context.debug_data.dt_hash` field. + - Historical analysis should indicate if this device token hash is commonly associated with the user. +- Review the `okta.event_type` field to determine the type of authentication event that occurred. + - If the event type is `user.authentication.sso`, the user may have legitimately started a session via a proxy for security or privacy reasons. + - If the event type is `user.authentication.password`, the user may be using a proxy to access multiple accounts for password spraying. + - If the event type is `user.session.start`, the source may have attempted to establish a session via the Okta authentication API. +- Examine the `okta.outcome.result` field to determine if the authentication was successful. +- Review the past activities of the actor(s) involved in this action by checking their previous actions. +- 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. + - This may help determine the authentication and authorization actions that occurred between the user, Okta and application. + + +*False positive analysis:* + +- A user may have legitimately started a session via a proxy for security or privacy reasons. +- Users may share an endpoint related to work or personal use in which separate Okta accounts are used. + - Architecturally, this shared endpoint may leverage a proxy for security or privacy reasons. + - Shared systems such as Kiosks and conference room computers may be used by multiple users. + - Shared working spaces may have a single endpoint that is used by multiple users. + + +*Response and remediation:* + +- Review the profile of the users involved in this action to determine if proxy usage may be expected. +- If the user is legitimate and the authentication behavior is not suspicious based on device analysis, no action is required. +- If the user is legitimate but the authentication behavior is suspicious, consider resetting passwords for the users involves and enabling multi-factor authentication (MFA). + - If MFA is already enabled, consider resetting MFA for the users. +- If any of the users are not legitimate, consider deactivating the user's account. +- Conduct a review of Okta policies and ensure they are in accordance with security best practices. +- Check with internal IT teams to determine if the accounts involved recently had MFA reset at the request of the user. + - If so, confirm with the user this was a legitimate request. + - If so and this was not a legitimate request, consider deactivating the user's account temporarily. + - Reset passwords and reset MFA for the user. +- If this is a false positive, consider adding the `okta.debug_context.debug_data.dt_hash` field to the `exceptions` list in the rule. + - This will prevent future occurrences of this event for this device from triggering the rule. + - Alternatively adding `okta.client.ip` or a CIDR range to the `exceptions` list can prevent future occurrences of this event from triggering the rule. + - This should be done with caution as it may prevent legitimate alerts from being generated. + + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-okta* +| WHERE + event.dataset == "okta.system" + AND (event.action RLIKE "user\\.authentication(.*)" OR event.action == "user.session.start") + AND okta.debug_context.debug_data.request_uri == "/api/v1/authn" + AND okta.outcome.reason == "INVALID_CREDENTIALS" +| STATS + source_auth_count = COUNT_DISTINCT(okta.debug_context.debug_data.dt_hash) + BY okta.client.ip, okta.actor.alternate_id +| WHERE + source_auth_count >= 30 +| SORT + source_auth_count DESC + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Credential Stuffing +** ID: T1110.004 +** Reference URL: https://attack.mitre.org/techniques/T1110/004/ diff --git a/docs/detections/prebuilt-rules/rule-details/multiple-okta-user-authentication-events-with-client-address.asciidoc b/docs/detections/prebuilt-rules/rule-details/multiple-okta-user-authentication-events-with-client-address.asciidoc new file mode 100644 index 0000000000..35d689ea2c --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/multiple-okta-user-authentication-events-with-client-address.asciidoc @@ -0,0 +1,151 @@ +[[multiple-okta-user-authentication-events-with-client-address]] +=== Multiple Okta User Authentication Events with Client Address + +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. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*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/ + +*Tags*: + +* Use Case: Identity and Access Audit +* Data Source: Okta +* Tactic: Credential Access + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Multiple Okta User Authentication Events with Client Address* + + +This 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. + + +*Possible investigation steps:* + +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. +- 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. +- 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. +- Review the `okta.security_context.is_proxy` field to determine if the device is a proxy. + - If the device is a proxy, this may indicate that a user is using a proxy to access multiple accounts for password spraying. +- With the list of `okta.actor.alternate_id` values, review `event.outcome` results to determine if the authentication was successful. + - If the authentication was successful for any user, pivoting to `event.action` values for those users may provide additional context. +- With Okta end users identified, review the `okta.debug_context.debug_data.dt_hash` field. + - Historical analysis should indicate if this device token hash is commonly associated with the user. +- Review the `okta.event_type` field to determine the type of authentication event that occurred. + - If the event type is `user.authentication.sso`, the user may have legitimately started a session via a proxy for security or privacy reasons. + - If the event type is `user.authentication.password`, the user may be using a proxy to access multiple accounts for password spraying. + - If the event type is `user.session.start`, the source may have attempted to establish a session via the Okta authentication API. +- Examine the `okta.outcome.result` field to determine if the authentication was successful. +- Review the past activities of the actor(s) involved in this action by checking their previous actions. +- 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. + - This may help determine the authentication and authorization actions that occurred between the user, Okta and application. + + +*False positive analysis:* + +- A user may have legitimately started a session via a proxy for security or privacy reasons. +- Users may share an endpoint related to work or personal use in which separate Okta accounts are used. + - Architecturally, this shared endpoint may leverage a proxy for security or privacy reasons. + - Shared systems such as Kiosks and conference room computers may be used by multiple users. + - Shared working spaces may have a single endpoint that is used by multiple users. + + +*Response and remediation:* + +- Review the profile of the users involved in this action to determine if proxy usage may be expected. +- If the user is legitimate and the authentication behavior is not suspicious based on device analysis, no action is required. +- If the user is legitimate but the authentication behavior is suspicious, consider resetting passwords for the users involves and enabling multi-factor authentication (MFA). + - If MFA is already enabled, consider resetting MFA for the users. +- If any of the users are not legitimate, consider deactivating the user's account. +- Conduct a review of Okta policies and ensure they are in accordance with security best practices. +- Check with internal IT teams to determine if the accounts involved recently had MFA reset at the request of the user. + - If so, confirm with the user this was a legitimate request. + - If so and this was not a legitimate request, consider deactivating the user's account temporarily. + - Reset passwords and reset MFA for the user. +- If this is a false positive, consider adding the `okta.debug_context.debug_data.dt_hash` field to the `exceptions` list in the rule. + - This will prevent future occurrences of this event for this device from triggering the rule. + - Alternatively adding `okta.client.ip` or a CIDR range to the `exceptions` list can prevent future occurrences of this event from triggering the rule. + - This should be done with caution as it may prevent legitimate alerts from being generated. + + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-okta* +| WHERE + event.dataset == "okta.system" + AND (event.action == "user.session.start" OR event.action RLIKE "user\\.authentication(.*)") + AND okta.outcome.reason == "INVALID_CREDENTIALS" +| STATS + source_auth_count = COUNT_DISTINCT(okta.actor.id) + BY okta.client.ip, okta.actor.alternate_id +| WHERE + source_auth_count > 5 +| SORT + source_auth_count DESC + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Credential Stuffing +** ID: T1110.004 +** Reference URL: https://attack.mitre.org/techniques/T1110/004/ diff --git a/docs/detections/prebuilt-rules/rule-details/multiple-okta-user-authentication-events-with-same-device-token-hash.asciidoc b/docs/detections/prebuilt-rules/rule-details/multiple-okta-user-authentication-events-with-same-device-token-hash.asciidoc new file mode 100644 index 0000000000..f2f88f151a --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/multiple-okta-user-authentication-events-with-same-device-token-hash.asciidoc @@ -0,0 +1,149 @@ +[[multiple-okta-user-authentication-events-with-same-device-token-hash]] +=== Multiple Okta User Authentication Events with Same Device Token Hash + +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. + +*Rule type*: esql + +*Rule indices*: None + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*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/ + +*Tags*: + +* Use Case: Identity and Access Audit +* Data Source: Okta +* Tactic: Credential Access + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and analysis* + + + +*Investigating Multiple Okta User Authentication Events with Same Device Token Hash* + + +This 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. + + +*Possible investigation steps:* + +- 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. +- 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. +- 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. +- Review the `okta.security_context.is_proxy` field to determine if the device is a proxy. + - If the device is a proxy, this may indicate that a user is using a proxy to access multiple accounts for password spraying. +- With the list of `okta.actor.alternate_id` values, review `event.outcome` results to determine if the authentication was successful. + - If the authentication was successful for any user, pivoting to `event.action` values for those users may provide additional context. +- With Okta end users identified, review the `okta.debug_context.debug_data.dt_hash` field. + - Historical analysis should indicate if this device token hash is commonly associated with the user. +- Review the `okta.event_type` field to determine the type of authentication event that occurred. + - If the event type is `user.authentication.sso`, the user may have legitimately started a session via a proxy for security or privacy reasons. + - If the event type is `user.authentication.password`, the user may be using a proxy to access multiple accounts for password spraying. +- Examine the `okta.outcome.result` field to determine if the authentication was successful. +- Review the past activities of the actor(s) involved in this action by checking their previous actions. +- 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. + - This may help determine the authentication and authorization actions that occurred between the user, Okta and application. + + +*False positive analysis:* + +- A user may have legitimately started a session via a proxy for security or privacy reasons. +- Users may share an endpoint related to work or personal use in which separate Okta accounts are used. + - Architecturally, this shared endpoint may leverage a proxy for security or privacy reasons. + - Shared systems such as Kiosks and conference room computers may be used by multiple users. + - Shared working spaces may have a single endpoint that is used by multiple users. + + +*Response and remediation:* + +- Review the profile of the users involved in this action to determine if proxy usage may be expected. +- If the user is legitimate and the authentication behavior is not suspicious based on device analysis, no action is required. +- If the user is legitimate but the authentication behavior is suspicious, consider resetting passwords for the users involves and enabling multi-factor authentication (MFA). + - If MFA is already enabled, consider resetting MFA for the users. +- If any of the users are not legitimate, consider deactivating the user's account. +- Conduct a review of Okta policies and ensure they are in accordance with security best practices. +- Check with internal IT teams to determine if the accounts involved recently had MFA reset at the request of the user. + - If so, confirm with the user this was a legitimate request. + - If so and this was not a legitimate request, consider deactivating the user's account temporarily. + - Reset passwords and reset MFA for the user. +- If this is a false positive, consider adding the `okta.debug_context.debug_data.dt_hash` field to the `exceptions` list in the rule. + - This will prevent future occurrences of this event for this device from triggering the rule. + + +==== Setup + + +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +==== Rule query + + +[source, js] +---------------------------------- +FROM logs-okta* +| WHERE + event.dataset == "okta.system" + AND (event.action RLIKE "user\\.authentication(.*)" OR event.action == "user.session.start") + AND okta.debug_context.debug_data.dt_hash != "-" + AND okta.outcome.reason == "INVALID_CREDENTIALS" +| STATS + target_auth_count = COUNT_DISTINCT(okta.actor.id) + BY okta.debug_context.debug_data.dt_hash, okta.actor.alternate_id +| WHERE + target_auth_count > 20 +| SORT + target_auth_count DESC + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Password Spraying +** ID: T1110.003 +** Reference URL: https://attack.mitre.org/techniques/T1110/003/ +* Technique: +** Name: Brute Force +** ID: T1110 +** Reference URL: https://attack.mitre.org/techniques/T1110/ +* Sub-technique: +** Name: Credential Stuffing +** ID: T1110.004 +** Reference URL: https://attack.mitre.org/techniques/T1110/004/ diff --git a/docs/detections/prebuilt-rules/rule-details/network-traffic-to-rare-destination-country.asciidoc b/docs/detections/prebuilt-rules/rule-details/network-traffic-to-rare-destination-country.asciidoc index 6714e07213..f79e4fdc04 100644 --- a/docs/detections/prebuilt-rules/rule-details/network-traffic-to-rare-destination-country.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/network-traffic-to-rare-destination-country.asciidoc @@ -27,7 +27,7 @@ A machine learning job detected a rare destination country name in the network l * Rule Type: ML * Rule Type: Machine Learning -*Version*: 103 +*Version*: 104 *Rule authors*: @@ -35,3 +35,65 @@ A machine learning job detected a rare destination country name in the network l *Rule license*: Elastic License v2 + +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Network Packet Capture + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Network Packet Capture Integration Setup* + +The 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 — 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. + + +*The following steps should be executed in order to add the Elastic Agent System integration "network_traffic" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Network Packet Capture” and select the integration to see more details about it. +- Click “Add Network Packet Capture”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “network_traffic” to an existing or a new agent policy, and deploy the agent on your system from which network log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/network_traffic[helper guide]. + diff --git a/docs/detections/prebuilt-rules/rule-details/ntds-dump-via-wbadmin.asciidoc b/docs/detections/prebuilt-rules/rule-details/ntds-dump-via-wbadmin.asciidoc new file mode 100644 index 0000000000..8da45c0ca2 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/ntds-dump-via-wbadmin.asciidoc @@ -0,0 +1,84 @@ +[[ntds-dump-via-wbadmin]] +=== NTDS Dump via Wbadmin + +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. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-endpoint.events.process-* +* logs-windows.* +* endgame-* +* logs-system.security* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://medium.com/r3d-buck3t/windows-privesc-with-sebackupprivilege-65d2cd1eb960 + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Elastic Endgame +* Data Source: Elastic Defend + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "windows" and event.type == "start" and + (process.name : "wbadmin.exe" or ?process.pe.original_file_name : "wbadmin.exe") and + process.args : "recovery" and process.command_line : "*ntds.dit*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: OS Credential Dumping +** ID: T1003 +** Reference URL: https://attack.mitre.org/techniques/T1003/ +* Sub-technique: +** Name: Security Account Manager +** ID: T1003.002 +** Reference URL: https://attack.mitre.org/techniques/T1003/002/ +* Sub-technique: +** Name: NTDS +** ID: T1003.003 +** Reference URL: https://attack.mitre.org/techniques/T1003/003/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ +* Technique: +** Name: Direct Volume Access +** ID: T1006 +** Reference URL: https://attack.mitre.org/techniques/T1006/ diff --git a/docs/detections/prebuilt-rules/rule-details/okta-user-sessions-started-from-different-geolocations.asciidoc b/docs/detections/prebuilt-rules/rule-details/okta-user-sessions-started-from-different-geolocations.asciidoc index 17bfcd5beb..8ef98b5984 100644 --- a/docs/detections/prebuilt-rules/rule-details/okta-user-sessions-started-from-different-geolocations.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/okta-user-sessions-started-from-different-geolocations.asciidoc @@ -1,14 +1,11 @@ [[okta-user-sessions-started-from-different-geolocations]] === Okta User Sessions Started from Different Geolocations -Detects when a specific Okta actor has multiple sessions started from different geolocations. +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. -*Rule type*: threshold +*Rule type*: esql -*Rule indices*: - -* filebeat-* -* logs-okta* +*Rule indices*: None *Severity*: medium @@ -34,7 +31,7 @@ Detects when a specific Okta actor has multiple sessions started from different * Data Source: Okta * Tactic: Initial Access -*Version*: 1 +*Version*: 101 *Rule authors*: @@ -48,18 +45,76 @@ Detects when a specific Okta actor has multiple sessions started from different +*Triage and analysis* + + + +*Investigating Okta User Sessions Started from Different Geolocations* + + +This 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. + + +*Possible investigation steps:* + +- 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. +- 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. +- 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. +- With Okta end users identified, review the `okta.debug_context.debug_data.dt_hash` field. + - Historical analysis should indicate if this device token hash is commonly associated with the user. +- Review the `okta.event_type` field to determine the type of authentication event that occurred. + - If the event type is `user.authentication.sso`, the user may have legitimately started a session via a proxy for security or privacy reasons. + - If the event type is `user.authentication.password`, the user may be using a proxy to access multiple accounts for password spraying. + - If the event type is `user.session.start`, the source may have attempted to establish a session via the Okta authentication API. +- Review the past activities of the actor(s) involved in this action by checking their previous actions. +- 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. + - This may help determine the authentication and authorization actions that occurred between the user, Okta and application. + + +*False positive analysis:* + +- It is very rare that a legitimate user would have multiple sessions started from different geo-located countries in a short time frame. + + +*Response and remediation:* + +- If the user is legitimate and the authentication behavior is not suspicious based on device analysis, no action is required. +- If the user is legitimate but the authentication behavior is suspicious, consider resetting passwords for the users involves and enabling multi-factor authentication (MFA). + - If MFA is already enabled, consider resetting MFA for the users. +- If any of the users are not legitimate, consider deactivating the user's account. +- Conduct a review of Okta policies and ensure they are in accordance with security best practices. +- Check with internal IT teams to determine if the accounts involved recently had MFA reset at the request of the user. + - If so, confirm with the user this was a legitimate request. + - If so and this was not a legitimate request, consider deactivating the user's account temporarily. + - Reset passwords and reset MFA for the user. +- If this is a false positive, consider adding the `okta.debug_context.debug_data.dt_hash` field to the `exceptions` list in the rule. + - This will prevent future occurrences of this event for this device from triggering the rule. + - Alternatively adding `okta.client.ip` or a CIDR range to the `exceptions` list can prevent future occurrences of this event from triggering the rule. + - This should be done with caution as it may prevent legitimate alerts from being generated. + + ==== Setup The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + ==== Rule query [source, js] ---------------------------------- -event.dataset:okta.system and okta.event_type:user.session.start and not okta.security_context.is_proxy:true - and okta.actor.id:* and client.geo.country_name:* +FROM logs-okta* +| WHERE + event.dataset == "okta.system" + AND (event.action RLIKE "user\\.authentication(.*)" OR event.action == "user.session.start") + AND okta.security_context.is_proxy != true and okta.actor.id != "unknown" + AND event.outcome == "success" +| STATS + geo_auth_counts = COUNT_DISTINCT(client.geo.country_name) + BY okta.actor.id, okta.actor.alternate_id +| WHERE + geo_auth_counts >= 2 ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/potential-persistence-via-file-modification.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-persistence-via-file-modification.asciidoc index cd76025de4..0e47acfb65 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-persistence-via-file-modification.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-persistence-via-file-modification.asciidoc @@ -31,7 +31,7 @@ This rule leverages the File Integrity Monitoring (FIM) integration to detect fi * Tactic: Privilege Escalation * Data Source: File Integrity Monitoring -*Version*: 1 +*Version*: 2 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-service-imagepath-modification.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-service-imagepath-modification.asciidoc new file mode 100644 index 0000000000..ca73253606 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-service-imagepath-modification.asciidoc @@ -0,0 +1,136 @@ +[[potential-privilege-escalation-via-service-imagepath-modification]] +=== Potential Privilege Escalation via Service ImagePath Modification + +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. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.registry-* +* logs-windows.sysmon_operational-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cube0x0.github.io/Pocing-Beyond-DA/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Execution +* Tactic: Privilege Escalation +* Data Source: Elastic Defend +* Data Source: Sysmon + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Rule query + + +[source, js] +---------------------------------- +registry where host.os.type == "windows" and event.type == "change" and process.executable != null and + event.action == "modification" and registry.value == "ImagePath" and + registry.key : ( + "*\\ADWS", "*\\AppHostSvc", "*\\AppReadiness", "*\\AudioEndpointBuilder", "*\\AxInstSV", "*\\camsvc", "*\\CertSvc", + "*\\COMSysApp", "*\\CscService", "*\\defragsvc", "*\\DeviceAssociationService", "*\\DeviceInstall", "*\\DevQueryBroker", + "*\\Dfs", "*\\DFSR", "*\\diagnosticshub.standardcollector.service", "*\\DiagTrack", "*\\DmEnrollmentSvc", "*\\DNS", + "*\\dot3svc", "*\\Eaphost", "*\\GraphicsPerfSvc", "*\\hidserv", "*\\HvHost", "*\\IISADMIN", "*\\IKEEXT", + "*\\InstallService", "*\\iphlpsvc", "*\\IsmServ", "*\\LanmanServer", "*\\MSiSCSI", "*\\NcbService", "*\\Netlogon", + "*\\Netman", "*\\NtFrs", "*\\PlugPlay", "*\\Power", "*\\PrintNotify", "*\\ProfSvc", "*\\PushToInstall", "*\\RSoPProv", + "*\\sacsvr", "*\\SENS", "*\\SensorDataService", "*\\SgrmBroker", "*\\ShellHWDetection", "*\\shpamsvc", "*\\StorSvc", + "*\\svsvc", "*\\swprv", "*\\SysMain", "*\\Themes", "*\\TieringEngineService", "*\\TokenBroker", "*\\TrkWks", + "*\\UALSVC", "*\\UserManager", "*\\vm3dservice", "*\\vmicguestinterface", "*\\vmicheartbeat", "*\\vmickvpexchange", + "*\\vmicrdv", "*\\vmicshutdown", "*\\vmicvmsession", "*\\vmicvss", "*\\vmvss", "*\\VSS", "*\\w3logsvc", "*\\W3SVC", + "*\\WalletService", "*\\WAS", "*\\wercplsupport", "*\\WerSvc", "*\\Winmgmt", "*\\wisvc", "*\\wmiApSrv", + "*\\WPDBusEnum", "*\\WSearch" + ) and + not ( + registry.data.strings : ( + "?:\\Windows\\system32\\*.exe", + "%systemroot%\\system32\\*.exe", + "%windir%\\system32\\*.exe", + "%SystemRoot%\\system32\\svchost.exe -k *", + "%windir%\\system32\\svchost.exe -k *" + ) and + not registry.data.strings : ( + "*\\cmd.exe", + "*\\cscript.exe", + "*\\ieexec.exe", + "*\\iexpress.exe", + "*\\installutil.exe", + "*\\Microsoft.Workflow.Compiler.exe", + "*\\msbuild.exe", + "*\\mshta.exe", + "*\\msiexec.exe", + "*\\msxsl.exe", + "*\\net.exe", + "*\\powershell.exe", + "*\\pwsh.exe", + "*\\reg.exe", + "*\\RegAsm.exe", + "*\\RegSvcs.exe", + "*\\regsvr32.exe", + "*\\rundll32.exe", + "*\\vssadmin.exe", + "*\\wbadmin.exe", + "*\\wmic.exe", + "*\\wscript.exe" + ) + ) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Sub-technique: +** Name: Windows Service +** ID: T1543.003 +** Reference URL: https://attack.mitre.org/techniques/T1543/003/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Sub-technique: +** Name: Services Registry Permissions Weakness +** ID: T1574.011 +** Reference URL: https://attack.mitre.org/techniques/T1574/011/ +* Tactic: +** Name: Execution +** ID: TA0002 +** Reference URL: https://attack.mitre.org/tactics/TA0002/ +* Technique: +** Name: System Services +** ID: T1569 +** Reference URL: https://attack.mitre.org/techniques/T1569/ +* Sub-technique: +** Name: Service Execution +** ID: T1569.002 +** Reference URL: https://attack.mitre.org/techniques/T1569/002/ diff --git a/docs/detections/prebuilt-rules/rule-details/potential-wpad-spoofing-via-dns-record-creation.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-wpad-spoofing-via-dns-record-creation.asciidoc new file mode 100644 index 0000000000..b4bcfa33cc --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/potential-wpad-spoofing-via-dns-record-creation.asciidoc @@ -0,0 +1,94 @@ +[[potential-wpad-spoofing-via-dns-record-creation]] +=== Potential WPAD Spoofing via DNS Record Creation + +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. + +*Rule type*: eql + +*Rule indices*: + +* winlogbeat-* +* logs-system.* +* logs-windows.* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://www.thehacker.recipes/ad/movement/mitm-and-coerced-authentications/wpad-spoofing#through-adidns-spoofing +* https://cube0x0.github.io/Pocing-Beyond-DA/ + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Credential Access +* Data Source: Active Directory +* Use Case: Active Directory Monitoring + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Setup + + + +*Setup* + + +The 'Audit Directory Service Changes' logging policy must be configured for (Success, Failure). +Steps to implement the logging policy with Advanced Audit Configuration: + +``` +Computer Configuration > +Policies > +Windows Settings > +Security Settings > +Advanced Audit Policies Configuration > +Audit Policies > +DS Access > +Audit Directory Service Changes (Success,Failure) +``` + +The 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. + +``` +Set-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 +``` + + +==== Rule query + + +[source, js] +---------------------------------- +any where host.os.type == "windows" and event.action == "Directory Service Changes" and + event.code == "5137" and winlog.event_data.ObjectDN : "DC=wpad,*" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Credential Access +** ID: TA0006 +** Reference URL: https://attack.mitre.org/tactics/TA0006/ +* Technique: +** Name: Adversary-in-the-Middle +** ID: T1557 +** Reference URL: https://attack.mitre.org/techniques/T1557/ diff --git a/docs/detections/prebuilt-rules/rule-details/rapid7-threat-command-cves-correlation.asciidoc b/docs/detections/prebuilt-rules/rule-details/rapid7-threat-command-cves-correlation.asciidoc new file mode 100644 index 0000000000..92c2500d9d --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/rapid7-threat-command-cves-correlation.asciidoc @@ -0,0 +1,117 @@ +[[rapid7-threat-command-cves-correlation]] +=== Rapid7 Threat Command CVEs Correlation + +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. + +*Rule type*: threat_match + +*Rule indices*: + +* auditbeat-* +* endgame-* +* filebeat-* +* logs-* +* packetbeat-* +* winlogbeat-* + +*Severity*: critical + +*Risk score*: 99 + +*Runs every*: 30m + +*Searches indices from*: now-35m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 10000 + +*References*: + +* https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-threatintel.html +* https://docs.elastic.co/integrations/ti_rapid7_threat_command + +*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 + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Investigation guide + + + +*Triage and Analysis* + + + +*Investigating Rapid7 Threat Command CVEs Correlation* + + +Rapid7 Threat Command CVEs Correlation rule allows matching CVEs from user indices within the vulnerabilities collected from Rapid7 Threat Command integrations. + +The 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. + +If a vulnerability matches a local observation, the following enriched fields will be generated to identify the vulnerability, field, and type matched. + +- `threat.indicator.matched.atomic` - this identifies the atomic vulnerability that matched the local observation +- `threat.indicator.matched.field` - this identifies the vulnerability field that matched the local observation +- `threat.indicator.matched.type` - this identifies the vulnerability type that matched the local observation + +Additional 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. + +- Investigation can be validated and reviewed based on the data that was matched and by viewing the source of that activity. +- 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. +- Consider the user and their role within the company: is this something related to their job or work function? + + +==== Setup + + + + +*Setup* + + +This rule needs threat intelligence indicators to work. +Threat intelligence indicators can be collected using an https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html#agent-ti-integration[Elastic Agent integration], +the https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html#ti-mod-integration[Threat Intel module], +or a https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html#custom-ti-integration[custom integration]. + +More information can be found https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html[here]. + + +*Max Signals* + + +This 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. + +**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. + +To 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. + +**NOTE:** Changing `xpack.alerting.rules.run.alerts.max` is not possible in Serverless projects. + + +==== Rule query + + +[source, js] +---------------------------------- +vulnerability.id : * + +---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/rare-aws-error-code.asciidoc b/docs/detections/prebuilt-rules/rule-details/rare-aws-error-code.asciidoc index fded439e4e..db6e32a775 100644 --- a/docs/detections/prebuilt-rules/rule-details/rare-aws-error-code.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/rare-aws-error-code.asciidoc @@ -30,7 +30,7 @@ A machine learning job detected an unusual error in a CloudTrail message. These * Rule Type: Machine Learning * Resources: Investigation Guide -*Version*: 208 +*Version*: 209 *Rule authors*: @@ -110,7 +110,36 @@ Detection alerts from this rule indicate a rare and unusual error code that was - Identify the initial vector abused by the attacker and take action to prevent reinfection via the same vector. - 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). + ==== Setup -The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from AWS. + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*AWS Integration Setup* + +The AWS integration allows you to collect logs and metrics from Amazon Web Services (AWS) with Elastic Agent. + + +*The following steps should be executed in order to add the Elastic Agent System integration "aws" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “AWS” and select the integration to see more details about it. +- Click “Add AWS”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “aws” to an existing or a new agent policy, and deploy the agent on your system from which aws log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://www.elastic.co/docs/current/integrations/aws[helper guide]. + diff --git a/docs/detections/prebuilt-rules/rule-details/rare-user-logon.asciidoc b/docs/detections/prebuilt-rules/rule-details/rare-user-logon.asciidoc index 33ed485149..2dd3d02fae 100644 --- a/docs/detections/prebuilt-rules/rule-details/rare-user-logon.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/rare-user-logon.asciidoc @@ -30,7 +30,7 @@ A machine learning job found an unusual user name in the authentication logs. An * Tactic: Initial Access * Resources: Investigation Guide -*Version*: 104 +*Version*: 105 *Rule authors*: @@ -76,6 +76,94 @@ This rule uses a machine learning job to detect an unusual user name in authenti - 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). +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Auditd Manager +- System + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditd Manager Integration Setup* + +The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel. +Auditd 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. + + +*The following steps should be executed in order to add the Elastic Agent System integration "auditd_manager" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Auditd Manager” and select the integration to see more details about it. +- Click “Add Auditd Manager”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “auditd manager” to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/auditd_manager[helper guide]. + + +*Rule Specific Setup Note* + +Auditd Manager subscribes to the kernel and receives events as they occur without any additional configuration. +However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from. +- For this detection rule no additional audit rules are required. + + +*System Integration Setup* + +The System integration allows you to collect system logs and metrics from your servers with Elastic Agent. + + +*The following steps should be executed in order to add the Elastic Agent System integration "system" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “System” and select the integration to see more details about it. +- Click “Add System”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “system” to an existing or a new agent policy, and deploy the agent on your system from which system log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/system[helper guide]. + + *Framework*: MITRE ATT&CK^TM^ * Tactic: diff --git a/docs/detections/prebuilt-rules/rule-details/spike-in-aws-error-messages.asciidoc b/docs/detections/prebuilt-rules/rule-details/spike-in-aws-error-messages.asciidoc index 74407e3825..963f1c7bc4 100644 --- a/docs/detections/prebuilt-rules/rule-details/spike-in-aws-error-messages.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/spike-in-aws-error-messages.asciidoc @@ -30,7 +30,7 @@ A machine learning job detected a significant spike in the rate of a particular * Rule Type: Machine Learning * Resources: Investigation Guide -*Version*: 208 +*Version*: 209 *Rule authors*: @@ -108,7 +108,36 @@ This rule uses a machine learning job to detect a significant spike in the rate - Identify the initial vector abused by the attacker and take action to prevent reinfection via the same vector. - 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). + ==== Setup -The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from AWS. + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*AWS Integration Setup* + +The AWS integration allows you to collect logs and metrics from Amazon Web Services (AWS) with Elastic Agent. + + +*The following steps should be executed in order to add the Elastic Agent System integration "aws" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “AWS” and select the integration to see more details about it. +- Click “Add AWS”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “aws” to an existing or a new agent policy, and deploy the agent on your system from which aws log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://www.elastic.co/docs/current/integrations/aws[helper guide]. + diff --git a/docs/detections/prebuilt-rules/rule-details/spike-in-failed-logon-events.asciidoc b/docs/detections/prebuilt-rules/rule-details/spike-in-failed-logon-events.asciidoc index a486334a42..45deaebeb9 100644 --- a/docs/detections/prebuilt-rules/rule-details/spike-in-failed-logon-events.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/spike-in-failed-logon-events.asciidoc @@ -30,7 +30,7 @@ A machine learning job found an unusually large spike in authentication failure * Tactic: Credential Access * Resources: Investigation Guide -*Version*: 104 +*Version*: 105 *Rule authors*: @@ -84,6 +84,94 @@ This rule uses a machine learning job to detect a substantial spike in failed au - 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). +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Auditd Manager +- System + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditd Manager Integration Setup* + +The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel. +Auditd 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. + + +*The following steps should be executed in order to add the Elastic Agent System integration "auditd_manager" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Auditd Manager” and select the integration to see more details about it. +- Click “Add Auditd Manager”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “auditd manager” to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/auditd_manager[helper guide]. + + +*Rule Specific Setup Note* + +Auditd Manager subscribes to the kernel and receives events as they occur without any additional configuration. +However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from. +- For this detection rule no additional audit rules are required. + + +*System Integration Setup* + +The System integration allows you to collect system logs and metrics from your servers with Elastic Agent. + + +*The following steps should be executed in order to add the Elastic Agent System integration "system" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “System” and select the integration to see more details about it. +- Click “Add System”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “system” to an existing or a new agent policy, and deploy the agent on your system from which system log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/system[helper guide]. + + *Framework*: MITRE ATT&CK^TM^ * Tactic: diff --git a/docs/detections/prebuilt-rules/rule-details/spike-in-firewall-denies.asciidoc b/docs/detections/prebuilt-rules/rule-details/spike-in-firewall-denies.asciidoc index 91b366b21c..b3f14d7f4e 100644 --- a/docs/detections/prebuilt-rules/rule-details/spike-in-firewall-denies.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/spike-in-firewall-denies.asciidoc @@ -27,7 +27,7 @@ A machine learning job detected an unusually large spike in network traffic that * Rule Type: ML * Rule Type: Machine Learning -*Version*: 103 +*Version*: 104 *Rule authors*: @@ -35,3 +35,65 @@ A machine learning job detected an unusually large spike in network traffic that *Rule license*: Elastic License v2 + +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Network Packet Capture + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Network Packet Capture Integration Setup* + +The 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 — 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. + + +*The following steps should be executed in order to add the Elastic Agent System integration "network_traffic" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Network Packet Capture” and select the integration to see more details about it. +- Click “Add Network Packet Capture”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “network_traffic” to an existing or a new agent policy, and deploy the agent on your system from which network log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/network_traffic[helper guide]. + diff --git a/docs/detections/prebuilt-rules/rule-details/spike-in-logon-events.asciidoc b/docs/detections/prebuilt-rules/rule-details/spike-in-logon-events.asciidoc index 9bc3bedd3d..b830309cf1 100644 --- a/docs/detections/prebuilt-rules/rule-details/spike-in-logon-events.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/spike-in-logon-events.asciidoc @@ -29,7 +29,7 @@ A machine learning job found an unusually large spike in successful authenticati * Rule Type: Machine Learning * Tactic: Credential Access -*Version*: 103 +*Version*: 104 *Rule authors*: @@ -38,6 +38,94 @@ A machine learning job found an unusually large spike in successful authenticati *Rule license*: Elastic License v2 +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Auditd Manager +- System + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditd Manager Integration Setup* + +The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel. +Auditd 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. + + +*The following steps should be executed in order to add the Elastic Agent System integration "auditd_manager" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Auditd Manager” and select the integration to see more details about it. +- Click “Add Auditd Manager”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “auditd manager” to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/auditd_manager[helper guide]. + + +*Rule Specific Setup Note* + +Auditd Manager subscribes to the kernel and receives events as they occur without any additional configuration. +However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from. +- For this detection rule no additional audit rules are required. + + +*System Integration Setup* + +The System integration allows you to collect system logs and metrics from your servers with Elastic Agent. + + +*The following steps should be executed in order to add the Elastic Agent System integration "system" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “System” and select the integration to see more details about it. +- Click “Add System”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “system” to an existing or a new agent policy, and deploy the agent on your system from which system log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/system[helper guide]. + + *Framework*: MITRE ATT&CK^TM^ * Tactic: diff --git a/docs/detections/prebuilt-rules/rule-details/spike-in-network-traffic-to-a-country.asciidoc b/docs/detections/prebuilt-rules/rule-details/spike-in-network-traffic-to-a-country.asciidoc index 3f3c06f315..098ade33f0 100644 --- a/docs/detections/prebuilt-rules/rule-details/spike-in-network-traffic-to-a-country.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/spike-in-network-traffic-to-a-country.asciidoc @@ -27,7 +27,7 @@ A machine learning job detected an unusually large spike in network activity to * Rule Type: ML * Rule Type: Machine Learning -*Version*: 104 +*Version*: 105 *Rule authors*: @@ -86,3 +86,65 @@ This rule uses a machine learning job to detect a significant spike in the netwo - Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. - 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). + +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Network Packet Capture + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Network Packet Capture Integration Setup* + +The 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 — 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. + + +*The following steps should be executed in order to add the Elastic Agent System integration "network_traffic" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Network Packet Capture” and select the integration to see more details about it. +- Click “Add Network Packet Capture”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “network_traffic” to an existing or a new agent policy, and deploy the agent on your system from which network log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/network_traffic[helper guide]. + diff --git a/docs/detections/prebuilt-rules/rule-details/spike-in-network-traffic.asciidoc b/docs/detections/prebuilt-rules/rule-details/spike-in-network-traffic.asciidoc index 64c640a676..8c2d739733 100644 --- a/docs/detections/prebuilt-rules/rule-details/spike-in-network-traffic.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/spike-in-network-traffic.asciidoc @@ -27,7 +27,7 @@ A machine learning job detected an unusually large spike in network traffic. Suc * Rule Type: ML * Rule Type: Machine Learning -*Version*: 103 +*Version*: 104 *Rule authors*: @@ -35,3 +35,65 @@ A machine learning job detected an unusually large spike in network traffic. Suc *Rule license*: Elastic License v2 + +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Network Packet Capture + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Network Packet Capture Integration Setup* + +The 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 — 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. + + +*The following steps should be executed in order to add the Elastic Agent System integration "network_traffic" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Network Packet Capture” and select the integration to see more details about it. +- Click “Add Network Packet Capture”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “network_traffic” to an existing or a new agent policy, and deploy the agent on your system from which network log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/network_traffic[helper guide]. + diff --git a/docs/detections/prebuilt-rules/rule-details/spike-in-successful-logon-events-from-a-source-ip.asciidoc b/docs/detections/prebuilt-rules/rule-details/spike-in-successful-logon-events-from-a-source-ip.asciidoc index 50ab860ea3..d5a4277489 100644 --- a/docs/detections/prebuilt-rules/rule-details/spike-in-successful-logon-events-from-a-source-ip.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/spike-in-successful-logon-events-from-a-source-ip.asciidoc @@ -31,7 +31,7 @@ A machine learning job found an unusually large spike in successful authenticati * Tactic: Defense Evasion * Resources: Investigation Guide -*Version*: 104 +*Version*: 105 *Rule authors*: @@ -79,6 +79,94 @@ This rule uses a machine learning job to detect a substantial spike in successfu - 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). +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Auditd Manager +- System + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditd Manager Integration Setup* + +The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel. +Auditd 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. + + +*The following steps should be executed in order to add the Elastic Agent System integration "auditd_manager" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Auditd Manager” and select the integration to see more details about it. +- Click “Add Auditd Manager”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “auditd manager” to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/auditd_manager[helper guide]. + + +*Rule Specific Setup Note* + +Auditd Manager subscribes to the kernel and receives events as they occur without any additional configuration. +However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from. +- For this detection rule no additional audit rules are required. + + +*System Integration Setup* + +The System integration allows you to collect system logs and metrics from your servers with Elastic Agent. + + +*The following steps should be executed in order to add the Elastic Agent System integration "system" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “System” and select the integration to see more details about it. +- Click “Add System”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “system” to an existing or a new agent policy, and deploy the agent on your system from which system log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/system[helper guide]. + + *Framework*: MITRE ATT&CK^TM^ * Tactic: diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-powershell-script.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-powershell-script.asciidoc index c06d6a8c8b..f923148edd 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-powershell-script.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-powershell-script.asciidoc @@ -31,7 +31,7 @@ A machine learning job detected a PowerShell script with unusual data characteri * Rule Type: Machine Learning * Tactic: Execution -*Version*: 104 +*Version*: 105 *Rule authors*: @@ -40,6 +40,68 @@ A machine learning job detected a PowerShell script with unusual data characteri *Rule license*: Elastic License v2 +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Windows + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Windows Integration Setup* + +The Windows integration allows you to monitor the Windows OS, services, applications, and more. + + +*The following steps should be executed in order to add the Elastic Agent System integration "windows" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Windows” and select the integration to see more details about it. +- Click “Add Windows”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “windows” to an existing or a new agent policy, and deploy the agent on your system from which windows log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/windows[helper guide]. + + *Framework*: MITRE ATT&CK^TM^ * Tactic: diff --git a/docs/detections/prebuilt-rules/rule-details/threat-intel-hash-indicator-match.asciidoc b/docs/detections/prebuilt-rules/rule-details/threat-intel-hash-indicator-match.asciidoc index d1acbc48a8..b9fa5b9562 100644 --- a/docs/detections/prebuilt-rules/rule-details/threat-intel-hash-indicator-match.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/threat-intel-hash-indicator-match.asciidoc @@ -33,9 +33,9 @@ This rule is triggered when a hash indicator from the Threat Intel Filebeat modu * OS: Windows * Data Source: Elastic Endgame -* Rule Type: Indicator Match +* Rule Type: Threat Match -*Version*: 7 +*Version*: 8 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/threat-intel-ip-address-indicator-match.asciidoc b/docs/detections/prebuilt-rules/rule-details/threat-intel-ip-address-indicator-match.asciidoc index 43e3dce2a0..e78145f025 100644 --- a/docs/detections/prebuilt-rules/rule-details/threat-intel-ip-address-indicator-match.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/threat-intel-ip-address-indicator-match.asciidoc @@ -34,9 +34,9 @@ This rule is triggered when an IP address indicator from the Threat Intel Filebe * OS: Windows * Data Source: Elastic Endgame -* Rule Type: Indicator Match +* Rule Type: Threat Match -*Version*: 6 +*Version*: 7 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/threat-intel-url-indicator-match.asciidoc b/docs/detections/prebuilt-rules/rule-details/threat-intel-url-indicator-match.asciidoc index 342a52c68c..5973ebde0a 100644 --- a/docs/detections/prebuilt-rules/rule-details/threat-intel-url-indicator-match.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/threat-intel-url-indicator-match.asciidoc @@ -34,9 +34,9 @@ This rule is triggered when a URL indicator from the Threat Intel Filebeat modul * OS: Windows * Data Source: Elastic Endgame -* Rule Type: Indicator Match +* Rule Type: Threat Match -*Version*: 6 +*Version*: 7 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/threat-intel-windows-registry-indicator-match.asciidoc b/docs/detections/prebuilt-rules/rule-details/threat-intel-windows-registry-indicator-match.asciidoc index 6da1eecf2f..c1373c39bc 100644 --- a/docs/detections/prebuilt-rules/rule-details/threat-intel-windows-registry-indicator-match.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/threat-intel-windows-registry-indicator-match.asciidoc @@ -33,9 +33,9 @@ This rule is triggered when a Windows registry indicator from the Threat Intel F * OS: Windows * Data Source: Elastic Endgame -* Rule Type: Indicator Match +* Rule Type: Threat Match -*Version*: 6 +*Version*: 7 *Rule authors*: diff --git a/docs/detections/prebuilt-rules/rule-details/unsigned-dll-loaded-by-dns-service.asciidoc b/docs/detections/prebuilt-rules/rule-details/unsigned-dll-loaded-by-dns-service.asciidoc new file mode 100644 index 0000000000..9271f3bcc0 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/unsigned-dll-loaded-by-dns-service.asciidoc @@ -0,0 +1,69 @@ +[[unsigned-dll-loaded-by-dns-service]] +=== Unsigned DLL loaded by DNS Service + +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. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.library-* +* logs-windows.sysmon_operational-* + +*Severity*: medium + +*Risk score*: 47 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://cube0x0.github.io/Pocing-Beyond-DA/ +* https://adsecurity.org/?p=4064 +* https://github.com/gtworek/PSBits/tree/master/ServerLevelPluginDll + +*Tags*: + +* Domain: Endpoint +* OS: Windows +* Use Case: Threat Detection +* Tactic: Privilege Escalation +* Data Source: Elastic Defend +* Data Source: Sysmon + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Rule query + + +[source, js] +---------------------------------- +any where host.os.type == "windows" and event.category : ("library", "process") and + event.type : ("start", "change") and event.action : ("load", "Image loaded*") and + process.executable : "?:\\windows\\system32\\dns.exe" and + not ?dll.code_signature.trusted == true and + not file.code_signature.status == "Valid" + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Privilege Escalation +** ID: TA0004 +** Reference URL: https://attack.mitre.org/tactics/TA0004/ +* Technique: +** Name: Exploitation for Privilege Escalation +** ID: T1068 +** Reference URL: https://attack.mitre.org/techniques/T1068/ diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-aws-command-for-a-user.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-aws-command-for-a-user.asciidoc index 888e7fae81..3860ad0a7d 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-aws-command-for-a-user.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-aws-command-for-a-user.asciidoc @@ -30,7 +30,7 @@ A machine learning job detected an AWS API command that, while not inherently su * Rule Type: Machine Learning * Resources: Investigation Guide -*Version*: 208 +*Version*: 209 *Rule authors*: @@ -110,7 +110,36 @@ Detection alerts from this rule indicate an AWS API command or method call that - Identify the initial vector abused by the attacker and take action to prevent reinfection via the same vector. - 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). + ==== Setup -The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from AWS. + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*AWS Integration Setup* + +The AWS integration allows you to collect logs and metrics from Amazon Web Services (AWS) with Elastic Agent. + + +*The following steps should be executed in order to add the Elastic Agent System integration "aws" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “AWS” and select the integration to see more details about it. +- Click “Add AWS”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “aws” to an existing or a new agent policy, and deploy the agent on your system from which aws log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://www.elastic.co/docs/current/integrations/aws[helper guide]. + diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-city-for-an-aws-command.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-city-for-an-aws-command.asciidoc index 905e0fa53c..85b1fc6477 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-city-for-an-aws-command.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-city-for-an-aws-command.asciidoc @@ -30,7 +30,7 @@ A machine learning job detected AWS command activity that, while not inherently * Rule Type: Machine Learning * Resources: Investigation Guide -*Version*: 208 +*Version*: 209 *Rule authors*: @@ -111,7 +111,36 @@ Detection alerts from this rule indicate an AWS API command or method call that - Identify the initial vector abused by the attacker and take action to prevent reinfection via the same vector. - 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). + ==== Setup -The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from AWS. + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*AWS Integration Setup* + +The AWS integration allows you to collect logs and metrics from Amazon Web Services (AWS) with Elastic Agent. + + +*The following steps should be executed in order to add the Elastic Agent System integration "aws" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “AWS” and select the integration to see more details about it. +- Click “Add AWS”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “aws” to an existing or a new agent policy, and deploy the agent on your system from which aws log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://www.elastic.co/docs/current/integrations/aws[helper guide]. + diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-country-for-an-aws-command.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-country-for-an-aws-command.asciidoc index 7012cce44d..b75cdcd62e 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-country-for-an-aws-command.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-country-for-an-aws-command.asciidoc @@ -30,7 +30,7 @@ A machine learning job detected AWS command activity that, while not inherently * Rule Type: Machine Learning * Resources: Investigation Guide -*Version*: 208 +*Version*: 209 *Rule authors*: @@ -111,7 +111,36 @@ Detection alerts from this rule indicate an AWS API command or method call that - Identify the initial vector abused by the attacker and take action to prevent reinfection via the same vector. - 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). + ==== Setup -The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from AWS. + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*AWS Integration Setup* + +The AWS integration allows you to collect logs and metrics from Amazon Web Services (AWS) with Elastic Agent. + + +*The following steps should be executed in order to add the Elastic Agent System integration "aws" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “AWS” and select the integration to see more details about it. +- Click “Add AWS”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “aws” to an existing or a new agent policy, and deploy the agent on your system from which aws log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://www.elastic.co/docs/current/integrations/aws[helper guide]. + diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-dns-activity.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-dns-activity.asciidoc index 4b6b00f11e..33010a4fab 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-dns-activity.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-dns-activity.asciidoc @@ -28,7 +28,7 @@ A machine learning job detected a rare and unusual DNS query that indicate netwo * Rule Type: Machine Learning * Tactic: Command and Control -*Version*: 103 +*Version*: 104 *Rule authors*: @@ -37,6 +37,68 @@ A machine learning job detected a rare and unusual DNS query that indicate netwo *Rule license*: Elastic License v2 +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Network Packet Capture + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Network Packet Capture Integration Setup* + +The 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 — 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. + + +*The following steps should be executed in order to add the Elastic Agent System integration "network_traffic" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Network Packet Capture” and select the integration to see more details about it. +- Click “Add Network Packet Capture”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “network_traffic” to an existing or a new agent policy, and deploy the agent on your system from which network log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/network_traffic[helper guide]. + + *Framework*: MITRE ATT&CK^TM^ * Tactic: diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-hour-for-a-user-to-logon.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-hour-for-a-user-to-logon.asciidoc index 50d11e77a5..7faaa80396 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-hour-for-a-user-to-logon.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-hour-for-a-user-to-logon.asciidoc @@ -30,7 +30,7 @@ A machine learning job detected a user logging in at a time of day that is unusu * Tactic: Initial Access * Resources: Investigation Guide -*Version*: 104 +*Version*: 105 *Rule authors*: @@ -76,6 +76,94 @@ This rule uses a machine learning job to detect a user logging in at a time of d - 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). +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Auditd Manager +- System + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditd Manager Integration Setup* + +The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel. +Auditd 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. + + +*The following steps should be executed in order to add the Elastic Agent System integration "auditd_manager" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Auditd Manager” and select the integration to see more details about it. +- Click “Add Auditd Manager”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “auditd manager” to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/auditd_manager[helper guide]. + + +*Rule Specific Setup Note* + +Auditd Manager subscribes to the kernel and receives events as they occur without any additional configuration. +However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from. +- For this detection rule no additional audit rules are required. + + +*System Integration Setup* + +The System integration allows you to collect system logs and metrics from your servers with Elastic Agent. + + +*The following steps should be executed in order to add the Elastic Agent System integration "system" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “System” and select the integration to see more details about it. +- Click “Add System”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “system” to an existing or a new agent policy, and deploy the agent on your system from which system log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/system[helper guide]. + + *Framework*: MITRE ATT&CK^TM^ * Tactic: diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-linux-network-activity.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-linux-network-activity.asciidoc index 9a141caad8..21455760d1 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-linux-network-activity.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-linux-network-activity.asciidoc @@ -29,7 +29,7 @@ Identifies Linux processes that do not usually use the network but have unexpect * Rule Type: ML * Rule Type: Machine Learning -*Version*: 103 +*Version*: 104 *Rule authors*: @@ -54,3 +54,73 @@ Detection alerts from this rule indicate the presence of network activity from a - 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? - 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. - 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. + +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Auditd Manager + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditd Manager Integration Setup* + +The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel. +Auditd 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. + + +*The following steps should be executed in order to add the Elastic Agent System integration "auditd_manager" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Auditd Manager” and select the integration to see more details about it. +- Click “Add Auditd Manager”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “auditd manager” to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/auditd_manager[helper guide]. + + +*Rule Specific Setup Note* + +Auditd Manager subscribes to the kernel and receives events as they occur without any additional configuration. +However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from. +- For this detection rule no additional audit rules are required. + diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-linux-network-configuration-discovery.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-linux-network-configuration-discovery.asciidoc index 5e9228bafb..b0eb52014d 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-linux-network-configuration-discovery.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-linux-network-configuration-discovery.asciidoc @@ -28,7 +28,7 @@ Looks for commands related to system network configuration discovery from an unu * Rule Type: Machine Learning * Tactic: Discovery -*Version*: 104 +*Version*: 105 *Rule authors*: @@ -37,6 +37,76 @@ Looks for commands related to system network configuration discovery from an unu *Rule license*: Elastic License v2 +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Auditd Manager + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditd Manager Integration Setup* + +The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel. +Auditd 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. + + +*The following steps should be executed in order to add the Elastic Agent System integration "auditd_manager" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Auditd Manager” and select the integration to see more details about it. +- Click “Add Auditd Manager”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “auditd manager” to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/auditd_manager[helper guide]. + + +*Rule Specific Setup Note* + +Auditd Manager subscribes to the kernel and receives events as they occur without any additional configuration. +However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from. +- For this detection rule no additional audit rules are required. + + *Framework*: MITRE ATT&CK^TM^ * Tactic: diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-linux-network-connection-discovery.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-linux-network-connection-discovery.asciidoc index f8cab62e2a..c598c6a371 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-linux-network-connection-discovery.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-linux-network-connection-discovery.asciidoc @@ -28,7 +28,7 @@ Looks for commands related to system network connection discovery from an unusua * Rule Type: Machine Learning * Tactic: Discovery -*Version*: 103 +*Version*: 104 *Rule authors*: @@ -37,6 +37,76 @@ Looks for commands related to system network connection discovery from an unusua *Rule license*: Elastic License v2 +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Auditd Manager + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditd Manager Integration Setup* + +The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel. +Auditd 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. + + +*The following steps should be executed in order to add the Elastic Agent System integration "auditd_manager" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Auditd Manager” and select the integration to see more details about it. +- Click “Add Auditd Manager”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “auditd manager” to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/auditd_manager[helper guide]. + + +*Rule Specific Setup Note* + +Auditd Manager subscribes to the kernel and receives events as they occur without any additional configuration. +However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from. +- For this detection rule no additional audit rules are required. + + *Framework*: MITRE ATT&CK^TM^ * Tactic: diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-linux-network-port-activity.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-linux-network-port-activity.asciidoc index ef998afa40..e831d28a93 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-linux-network-port-activity.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-linux-network-port-activity.asciidoc @@ -29,7 +29,7 @@ Identifies unusual destination port activity that can indicate command-and-contr * Rule Type: ML * Rule Type: Machine Learning -*Version*: 103 +*Version*: 104 *Rule authors*: @@ -37,3 +37,73 @@ Identifies unusual destination port activity that can indicate command-and-contr *Rule license*: Elastic License v2 + +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Auditd Manager + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditd Manager Integration Setup* + +The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel. +Auditd 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. + + +*The following steps should be executed in order to add the Elastic Agent System integration "auditd_manager" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Auditd Manager” and select the integration to see more details about it. +- Click “Add Auditd Manager”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “auditd manager” to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/auditd_manager[helper guide]. + + +*Rule Specific Setup Note* + +Auditd Manager subscribes to the kernel and receives events as they occur without any additional configuration. +However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from. +- For this detection rule no additional audit rules are required. + diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-linux-process-calling-the-metadata-service.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-linux-process-calling-the-metadata-service.asciidoc index 93f8c231f1..83abc825ee 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-linux-process-calling-the-metadata-service.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-linux-process-calling-the-metadata-service.asciidoc @@ -28,7 +28,7 @@ Looks for anomalous access to the metadata service by an unusual process. The me * Rule Type: Machine Learning * Tactic: Credential Access -*Version*: 103 +*Version*: 104 *Rule authors*: @@ -37,6 +37,76 @@ Looks for anomalous access to the metadata service by an unusual process. The me *Rule license*: Elastic License v2 +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Auditd Manager + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditd Manager Integration Setup* + +The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel. +Auditd 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. + + +*The following steps should be executed in order to add the Elastic Agent System integration "auditd_manager" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Auditd Manager” and select the integration to see more details about it. +- Click “Add Auditd Manager”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “auditd manager” to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/auditd_manager[helper guide]. + + +*Rule Specific Setup Note* + +Auditd Manager subscribes to the kernel and receives events as they occur without any additional configuration. +However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from. +- For this detection rule no additional audit rules are required. + + *Framework*: MITRE ATT&CK^TM^ * Tactic: diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-linux-process-discovery-activity.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-linux-process-discovery-activity.asciidoc index 2dd7956e27..70278737c4 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-linux-process-discovery-activity.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-linux-process-discovery-activity.asciidoc @@ -28,7 +28,7 @@ Looks for commands related to system process discovery from an unusual user cont * Rule Type: Machine Learning * Tactic: Discovery -*Version*: 103 +*Version*: 104 *Rule authors*: @@ -37,6 +37,76 @@ Looks for commands related to system process discovery from an unusual user cont *Rule license*: Elastic License v2 +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Auditd Manager + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditd Manager Integration Setup* + +The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel. +Auditd 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. + + +*The following steps should be executed in order to add the Elastic Agent System integration "auditd_manager" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Auditd Manager” and select the integration to see more details about it. +- Click “Add Auditd Manager”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “auditd manager” to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/auditd_manager[helper guide]. + + +*Rule Specific Setup Note* + +Auditd Manager subscribes to the kernel and receives events as they occur without any additional configuration. +However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from. +- For this detection rule no additional audit rules are required. + + *Framework*: MITRE ATT&CK^TM^ * Tactic: diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-linux-system-information-discovery-activity.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-linux-system-information-discovery-activity.asciidoc index e0e3f8fe7f..93b391c992 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-linux-system-information-discovery-activity.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-linux-system-information-discovery-activity.asciidoc @@ -28,7 +28,7 @@ Looks for commands related to system information discovery from an unusual user * Rule Type: Machine Learning * Tactic: Discovery -*Version*: 103 +*Version*: 104 *Rule authors*: @@ -37,6 +37,76 @@ Looks for commands related to system information discovery from an unusual user *Rule license*: Elastic License v2 +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Auditd Manager + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditd Manager Integration Setup* + +The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel. +Auditd 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. + + +*The following steps should be executed in order to add the Elastic Agent System integration "auditd_manager" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Auditd Manager” and select the integration to see more details about it. +- Click “Add Auditd Manager”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “auditd manager” to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/auditd_manager[helper guide]. + + +*Rule Specific Setup Note* + +Auditd Manager subscribes to the kernel and receives events as they occur without any additional configuration. +However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from. +- For this detection rule no additional audit rules are required. + + *Framework*: MITRE ATT&CK^TM^ * Tactic: diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-linux-user-calling-the-metadata-service.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-linux-user-calling-the-metadata-service.asciidoc index 79639c36b8..877bcdda4a 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-linux-user-calling-the-metadata-service.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-linux-user-calling-the-metadata-service.asciidoc @@ -28,7 +28,7 @@ Looks for anomalous access to the cloud platform metadata service by an unusual * Rule Type: Machine Learning * Tactic: Credential Access -*Version*: 103 +*Version*: 104 *Rule authors*: @@ -37,6 +37,76 @@ Looks for anomalous access to the cloud platform metadata service by an unusual *Rule license*: Elastic License v2 +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Auditd Manager + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditd Manager Integration Setup* + +The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel. +Auditd 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. + + +*The following steps should be executed in order to add the Elastic Agent System integration "auditd_manager" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Auditd Manager” and select the integration to see more details about it. +- Click “Add Auditd Manager”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “auditd manager” to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/auditd_manager[helper guide]. + + +*Rule Specific Setup Note* + +Auditd Manager subscribes to the kernel and receives events as they occur without any additional configuration. +However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from. +- For this detection rule no additional audit rules are required. + + *Framework*: MITRE ATT&CK^TM^ * Tactic: diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-linux-user-discovery-activity.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-linux-user-discovery-activity.asciidoc index 9df9d4cba7..11bb837f64 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-linux-user-discovery-activity.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-linux-user-discovery-activity.asciidoc @@ -28,7 +28,7 @@ Looks for commands related to system user or owner discovery from an unusual use * Rule Type: Machine Learning * Tactic: Discovery -*Version*: 104 +*Version*: 105 *Rule authors*: @@ -37,6 +37,76 @@ Looks for commands related to system user or owner discovery from an unusual use *Rule license*: Elastic License v2 +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Auditd Manager + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditd Manager Integration Setup* + +The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel. +Auditd 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. + + +*The following steps should be executed in order to add the Elastic Agent System integration "auditd_manager" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Auditd Manager” and select the integration to see more details about it. +- Click “Add Auditd Manager”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “auditd manager” to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/auditd_manager[helper guide]. + + +*Rule Specific Setup Note* + +Auditd Manager subscribes to the kernel and receives events as they occur without any additional configuration. +However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from. +- For this detection rule no additional audit rules are required. + + *Framework*: MITRE ATT&CK^TM^ * Tactic: diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-linux-username.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-linux-username.asciidoc index c0d065d500..cc9e93360a 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-linux-username.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-linux-username.asciidoc @@ -30,7 +30,7 @@ A machine learning job detected activity for a username that is not normally act * Rule Type: Machine Learning * Tactic: Initial Access -*Version*: 103 +*Version*: 104 *Rule authors*: @@ -54,6 +54,76 @@ Detection alerts from this rule indicate activity for a Linux user name that is - 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. - 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. +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Auditd Manager + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditd Manager Integration Setup* + +The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel. +Auditd 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. + + +*The following steps should be executed in order to add the Elastic Agent System integration "auditd_manager" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Auditd Manager” and select the integration to see more details about it. +- Click “Add Auditd Manager”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “auditd manager” to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/auditd_manager[helper guide]. + + +*Rule Specific Setup Note* + +Auditd Manager subscribes to the kernel and receives events as they occur without any additional configuration. +However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from. +- For this detection rule no additional audit rules are required. + + *Framework*: MITRE ATT&CK^TM^ * Tactic: diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-login-activity.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-login-activity.asciidoc index a6513138cb..563e5605bb 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-login-activity.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-login-activity.asciidoc @@ -29,7 +29,7 @@ Identifies an unusually high number of authentication attempts. * Rule Type: Machine Learning * Tactic: Credential Access -*Version*: 103 +*Version*: 104 *Rule authors*: @@ -38,6 +38,94 @@ Identifies an unusually high number of authentication attempts. *Rule license*: Elastic License v2 +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Auditd Manager +- System + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditd Manager Integration Setup* + +The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel. +Auditd 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. + + +*The following steps should be executed in order to add the Elastic Agent System integration "auditd_manager" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Auditd Manager” and select the integration to see more details about it. +- Click “Add Auditd Manager”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “auditd manager” to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/auditd_manager[helper guide]. + + +*Rule Specific Setup Note* + +Auditd Manager subscribes to the kernel and receives events as they occur without any additional configuration. +However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from. +- For this detection rule no additional audit rules are required. + + +*System Integration Setup* + +The System integration allows you to collect system logs and metrics from your servers with Elastic Agent. + + +*The following steps should be executed in order to add the Elastic Agent System integration "system" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “System” and select the integration to see more details about it. +- Click “Add System”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “system” to an existing or a new agent policy, and deploy the agent on your system from which system log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/system[helper guide]. + + *Framework*: MITRE ATT&CK^TM^ * Tactic: diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-network-destination-domain-name.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-network-destination-domain-name.asciidoc index 45f3f564fb..3975b59561 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-network-destination-domain-name.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-network-destination-domain-name.asciidoc @@ -27,7 +27,7 @@ A machine learning job detected an unusual network destination domain name. This * Rule Type: ML * Rule Type: Machine Learning -*Version*: 103 +*Version*: 104 *Rule authors*: @@ -35,3 +35,73 @@ A machine learning job detected an unusual network destination domain name. This *Rule license*: Elastic License v2 + +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Auditd Manager + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditd Manager Integration Setup* + +The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel. +Auditd 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. + + +*The following steps should be executed in order to add the Elastic Agent System integration "auditd_manager" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Auditd Manager” and select the integration to see more details about it. +- Click “Add Auditd Manager”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “auditd manager” to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/auditd_manager[helper guide]. + + +*Rule Specific Setup Note* + +Auditd Manager subscribes to the kernel and receives events as they occur without any additional configuration. +However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from. +- For this detection rule no additional audit rules are required. + diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-process-for-a-linux-host.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-process-for-a-linux-host.asciidoc index 673eacf555..7dd4cb28df 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-process-for-a-linux-host.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-process-for-a-linux-host.asciidoc @@ -30,7 +30,7 @@ Identifies rare processes that do not usually run on individual hosts, which can * Rule Type: Machine Learning * Tactic: Persistence -*Version*: 104 +*Version*: 105 *Rule authors*: @@ -90,6 +90,76 @@ This rule uses a machine learning job to detect a Linux process that is rare and - 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). +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Auditd Manager + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditd Manager Integration Setup* + +The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel. +Auditd 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. + + +*The following steps should be executed in order to add the Elastic Agent System integration "auditd_manager" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Auditd Manager” and select the integration to see more details about it. +- Click “Add Auditd Manager”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “auditd manager” to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/auditd_manager[helper guide]. + + +*Rule Specific Setup Note* + +Auditd Manager subscribes to the kernel and receives events as they occur without any additional configuration. +However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from. +- For this detection rule no additional audit rules are required. + + *Framework*: MITRE ATT&CK^TM^ * Tactic: diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-process-for-a-windows-host.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-process-for-a-windows-host.asciidoc index d7ca931b2d..0e97564e74 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-process-for-a-windows-host.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-process-for-a-windows-host.asciidoc @@ -31,7 +31,7 @@ Identifies rare processes that do not usually run on individual hosts, which can * Tactic: Persistence * Resources: Investigation Guide -*Version*: 108 +*Version*: 109 *Rule authors*: @@ -117,6 +117,68 @@ This rule uses a machine learning job to detect a Windows process that is rare a - 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). +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Windows + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Windows Integration Setup* + +The Windows integration allows you to monitor the Windows OS, services, applications, and more. + + +*The following steps should be executed in order to add the Elastic Agent System integration "windows" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Windows” and select the integration to see more details about it. +- Click “Add Windows”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “windows” to an existing or a new agent policy, and deploy the agent on your system from which windows log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/windows[helper guide]. + + *Framework*: MITRE ATT&CK^TM^ * Tactic: diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-source-ip-for-a-user-to-logon-from.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-source-ip-for-a-user-to-logon-from.asciidoc index 8da533fe37..81129aa328 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-source-ip-for-a-user-to-logon-from.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-source-ip-for-a-user-to-logon-from.asciidoc @@ -29,7 +29,7 @@ A machine learning job detected a user logging in from an IP address that is unu * Rule Type: Machine Learning * Tactic: Initial Access -*Version*: 103 +*Version*: 104 *Rule authors*: @@ -38,6 +38,94 @@ A machine learning job detected a user logging in from an IP address that is unu *Rule license*: Elastic License v2 +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Auditd Manager +- System + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditd Manager Integration Setup* + +The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel. +Auditd 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. + + +*The following steps should be executed in order to add the Elastic Agent System integration "auditd_manager" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Auditd Manager” and select the integration to see more details about it. +- Click “Add Auditd Manager”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “auditd manager” to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/auditd_manager[helper guide]. + + +*Rule Specific Setup Note* + +Auditd Manager subscribes to the kernel and receives events as they occur without any additional configuration. +However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from. +- For this detection rule no additional audit rules are required. + + +*System Integration Setup* + +The System integration allows you to collect system logs and metrics from your servers with Elastic Agent. + + +*The following steps should be executed in order to add the Elastic Agent System integration "system" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “System” and select the integration to see more details about it. +- Click “Add System”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “system” to an existing or a new agent policy, and deploy the agent on your system from which system log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/system[helper guide]. + + *Framework*: MITRE ATT&CK^TM^ * Tactic: diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-sudo-activity.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-sudo-activity.asciidoc index c74c5d6af9..ceb94ed2c1 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-sudo-activity.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-sudo-activity.asciidoc @@ -28,7 +28,7 @@ Looks for sudo activity from an unusual user context. An unusual sudo user could * Rule Type: Machine Learning * Tactic: Privilege Escalation -*Version*: 103 +*Version*: 104 *Rule authors*: @@ -37,6 +37,76 @@ Looks for sudo activity from an unusual user context. An unusual sudo user could *Rule license*: Elastic License v2 +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Auditd Manager + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Auditd Manager Integration Setup* + +The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel. +Auditd 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. + + +*The following steps should be executed in order to add the Elastic Agent System integration "auditd_manager" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Auditd Manager” and select the integration to see more details about it. +- Click “Add Auditd Manager”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “auditd manager” to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/auditd_manager[helper guide]. + + +*Rule Specific Setup Note* + +Auditd Manager subscribes to the kernel and receives events as they occur without any additional configuration. +However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from. +- For this detection rule no additional audit rules are required. + + *Framework*: MITRE ATT&CK^TM^ * Tactic: diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-web-request.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-web-request.asciidoc index 6b7c2c5881..a72304aa67 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-web-request.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-web-request.asciidoc @@ -28,7 +28,7 @@ A machine learning job detected a rare and unusual URL that indicates unusual we * Rule Type: Machine Learning * Tactic: Command and Control -*Version*: 103 +*Version*: 104 *Rule authors*: @@ -37,6 +37,68 @@ A machine learning job detected a rare and unusual URL that indicates unusual we *Rule license*: Elastic License v2 +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Network Packet Capture + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Network Packet Capture Integration Setup* + +The 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 — 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. + + +*The following steps should be executed in order to add the Elastic Agent System integration "network_traffic" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Network Packet Capture” and select the integration to see more details about it. +- Click “Add Network Packet Capture”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “network_traffic” to an existing or a new agent policy, and deploy the agent on your system from which network log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/network_traffic[helper guide]. + + *Framework*: MITRE ATT&CK^TM^ * Tactic: diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-web-user-agent.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-web-user-agent.asciidoc index 2a991b5def..12ecc17c37 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-web-user-agent.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-web-user-agent.asciidoc @@ -28,7 +28,7 @@ A machine learning job detected a rare and unusual user agent indicating web bro * Rule Type: Machine Learning * Tactic: Command and Control -*Version*: 103 +*Version*: 104 *Rule authors*: @@ -37,6 +37,68 @@ A machine learning job detected a rare and unusual user agent indicating web bro *Rule license*: Elastic License v2 +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Network Packet Capture + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Network Packet Capture Integration Setup* + +The 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 — 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. + + +*The following steps should be executed in order to add the Elastic Agent System integration "network_traffic" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Network Packet Capture” and select the integration to see more details about it. +- Click “Add Network Packet Capture”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “network_traffic” to an existing or a new agent policy, and deploy the agent on your system from which network log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/network_traffic[helper guide]. + + *Framework*: MITRE ATT&CK^TM^ * Tactic: diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-windows-network-activity.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-windows-network-activity.asciidoc index 4916756fa0..f6dcfc059e 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-windows-network-activity.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-windows-network-activity.asciidoc @@ -29,7 +29,7 @@ Identifies Windows processes that do not usually use the network but have unexpe * Rule Type: ML * Rule Type: Machine Learning -*Version*: 103 +*Version*: 104 *Rule authors*: @@ -56,3 +56,65 @@ Detection alerts from this rule indicate the presence of network activity from a - 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. - 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. - 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. + +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Windows + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Windows Integration Setup* + +The Windows integration allows you to monitor the Windows OS, services, applications, and more. + + +*The following steps should be executed in order to add the Elastic Agent System integration "windows" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Windows” and select the integration to see more details about it. +- Click “Add Windows”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “windows” to an existing or a new agent policy, and deploy the agent on your system from which windows log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/windows[helper guide]. + diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-windows-path-activity.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-windows-path-activity.asciidoc index 2b1f861d33..91006c7a03 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-windows-path-activity.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-windows-path-activity.asciidoc @@ -31,7 +31,7 @@ Identifies processes started from atypical folders in the file system, which mig * Tactic: Persistence * Tactic: Execution -*Version*: 104 +*Version*: 105 *Rule authors*: @@ -40,6 +40,68 @@ Identifies processes started from atypical folders in the file system, which mig *Rule license*: Elastic License v2 +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Windows + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Windows Integration Setup* + +The Windows integration allows you to monitor the Windows OS, services, applications, and more. + + +*The following steps should be executed in order to add the Elastic Agent System integration "windows" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Windows” and select the integration to see more details about it. +- Click “Add Windows”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “windows” to an existing or a new agent policy, and deploy the agent on your system from which windows log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/windows[helper guide]. + + *Framework*: MITRE ATT&CK^TM^ * Tactic: diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-windows-process-calling-the-metadata-service.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-windows-process-calling-the-metadata-service.asciidoc index 67f51cf52b..9ce27fd029 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-windows-process-calling-the-metadata-service.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-windows-process-calling-the-metadata-service.asciidoc @@ -28,7 +28,7 @@ Looks for anomalous access to the metadata service by an unusual process. The me * Rule Type: Machine Learning * Tactic: Credential Access -*Version*: 103 +*Version*: 104 *Rule authors*: @@ -37,6 +37,68 @@ Looks for anomalous access to the metadata service by an unusual process. The me *Rule license*: Elastic License v2 +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Windows + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Windows Integration Setup* + +The Windows integration allows you to monitor the Windows OS, services, applications, and more. + + +*The following steps should be executed in order to add the Elastic Agent System integration "windows" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Windows” and select the integration to see more details about it. +- Click “Add Windows”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “windows” to an existing or a new agent policy, and deploy the agent on your system from which windows log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/windows[helper guide]. + + *Framework*: MITRE ATT&CK^TM^ * Tactic: diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-windows-remote-user.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-windows-remote-user.asciidoc index 4b08d9e2c6..29496f5836 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-windows-remote-user.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-windows-remote-user.asciidoc @@ -30,7 +30,7 @@ A machine learning job detected an unusual remote desktop protocol (RDP) usernam * Rule Type: Machine Learning * Tactic: Initial Access -*Version*: 103 +*Version*: 104 *Rule authors*: @@ -53,6 +53,68 @@ Detection alerts from this rule indicate activity for a rare and unusual Windows - 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? - 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? +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Windows + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Windows Integration Setup* + +The Windows integration allows you to monitor the Windows OS, services, applications, and more. + + +*The following steps should be executed in order to add the Elastic Agent System integration "windows" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Windows” and select the integration to see more details about it. +- Click “Add Windows”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “windows” to an existing or a new agent policy, and deploy the agent on your system from which windows log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/windows[helper guide]. + + *Framework*: MITRE ATT&CK^TM^ * Tactic: diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-windows-service.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-windows-service.asciidoc index cfd865d646..1d688b51d6 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-windows-service.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-windows-service.asciidoc @@ -30,7 +30,7 @@ A machine learning job detected an unusual Windows service, This can indicate ex * Rule Type: Machine Learning * Tactic: Persistence -*Version*: 103 +*Version*: 104 *Rule authors*: @@ -39,6 +39,68 @@ A machine learning job detected an unusual Windows service, This can indicate ex *Rule license*: Elastic License v2 +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Windows + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Windows Integration Setup* + +The Windows integration allows you to monitor the Windows OS, services, applications, and more. + + +*The following steps should be executed in order to add the Elastic Agent System integration "windows" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Windows” and select the integration to see more details about it. +- Click “Add Windows”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “windows” to an existing or a new agent policy, and deploy the agent on your system from which windows log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/windows[helper guide]. + + *Framework*: MITRE ATT&CK^TM^ * Tactic: diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-windows-user-calling-the-metadata-service.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-windows-user-calling-the-metadata-service.asciidoc index eb565274ae..dd562bf8c0 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-windows-user-calling-the-metadata-service.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-windows-user-calling-the-metadata-service.asciidoc @@ -28,7 +28,7 @@ Looks for anomalous access to the cloud platform metadata service by an unusual * Rule Type: Machine Learning * Tactic: Credential Access -*Version*: 103 +*Version*: 104 *Rule authors*: @@ -37,6 +37,68 @@ Looks for anomalous access to the cloud platform metadata service by an unusual *Rule license*: Elastic License v2 +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Windows + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Windows Integration Setup* + +The Windows integration allows you to monitor the Windows OS, services, applications, and more. + + +*The following steps should be executed in order to add the Elastic Agent System integration "windows" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Windows” and select the integration to see more details about it. +- Click “Add Windows”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “windows” to an existing or a new agent policy, and deploy the agent on your system from which windows log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/windows[helper guide]. + + *Framework*: MITRE ATT&CK^TM^ * Tactic: diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-windows-user-privilege-elevation-activity.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-windows-user-privilege-elevation-activity.asciidoc index 36716d1e03..8a286bee1b 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-windows-user-privilege-elevation-activity.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-windows-user-privilege-elevation-activity.asciidoc @@ -30,7 +30,7 @@ A machine learning job detected an unusual user context switch, using the runas * Rule Type: Machine Learning * Tactic: Privilege Escalation -*Version*: 103 +*Version*: 104 *Rule authors*: @@ -39,6 +39,68 @@ A machine learning job detected an unusual user context switch, using the runas *Rule license*: Elastic License v2 +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Windows + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Windows Integration Setup* + +The Windows integration allows you to monitor the Windows OS, services, applications, and more. + + +*The following steps should be executed in order to add the Elastic Agent System integration "windows" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Windows” and select the integration to see more details about it. +- Click “Add Windows”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “windows” to an existing or a new agent policy, and deploy the agent on your system from which windows log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/windows[helper guide]. + + *Framework*: MITRE ATT&CK^TM^ * Tactic: diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-windows-username.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-windows-username.asciidoc index 17d4473ba5..edf620eeed 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-windows-username.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-windows-username.asciidoc @@ -30,7 +30,7 @@ A machine learning job detected activity for a username that is not normally act * Rule Type: Machine Learning * Tactic: Initial Access -*Version*: 104 +*Version*: 105 *Rule authors*: @@ -55,6 +55,68 @@ Detection alerts from this rule indicate activity for a Windows user name that i - 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. - 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. +==== Setup + + + +*Setup* + + +This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations: +- Elastic Defend +- Windows + + +*Anomaly Detection Setup* + + +Once 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 https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html[helper guide]. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration to your system:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/current/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +*Windows Integration Setup* + +The Windows integration allows you to monitor the Windows OS, services, applications, and more. + + +*The following steps should be executed in order to add the Elastic Agent System integration "windows" to your system:* + +- Go to the Kibana home page and click “Add integrations”. +- In the query bar, search for “Windows” and select the integration to see more details about it. +- Click “Add Windows”. +- Configure the integration name and optionally add a description. +- Review optional and advanced settings accordingly. +- Add the newly installed “windows” to an existing or a new agent policy, and deploy the agent on your system from which windows log files are desirable. +- Click “Save and Continue”. +- For more details on the integration refer to the https://docs.elastic.co/integrations/windows[helper guide]. + + *Framework*: MITRE ATT&CK^TM^ * Tactic: diff --git a/docs/detections/prebuilt-rules/rule-details/yum-dnf-plugin-status-discovery.asciidoc b/docs/detections/prebuilt-rules/rule-details/yum-dnf-plugin-status-discovery.asciidoc new file mode 100644 index 0000000000..c535dddf52 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/yum-dnf-plugin-status-discovery.asciidoc @@ -0,0 +1,101 @@ +[[yum-dnf-plugin-status-discovery]] +=== Yum/DNF Plugin Status Discovery + +This rule detects the execution of the `grep` command with the `plugins` argument on Linux systems. This command is used to search for YUM/DNF configurations and/or plugins with an enabled state. This behavior may indicate an attacker is attempting to establish persistence in a YUM or DNF plugin. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.* +* endgame-* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/linux/local/yum_package_manager_persistence.rb +* https://pwnshift.github.io/2020/10/01/persistence.html + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Discovery +* Data Source: Elastic Defend +* Data Source: Elastic Endgame + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Setup + + + +*Setup* + +This rule requires data coming in from Elastic Defend. + +*Elastic Defend Integration Setup* + +Elastic 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. + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event") and +process.name == "grep" and process.args : "plugins*" and process.args : ( + "/etc/yum.conf", "/usr/lib/yum-plugins/*", "/etc/yum/pluginconf.d/*", + "/usr/lib/python*/site-packages/dnf-plugins/*", "/etc/dnf/plugins/*", "/etc/dnf/dnf.conf" +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Discovery +** ID: TA0007 +** Reference URL: https://attack.mitre.org/tactics/TA0007/ +* Technique: +** Name: System Information Discovery +** ID: T1082 +** Reference URL: https://attack.mitre.org/techniques/T1082/ diff --git a/docs/detections/prebuilt-rules/rule-details/yum-package-manager-plugin-file-creation.asciidoc b/docs/detections/prebuilt-rules/rule-details/yum-package-manager-plugin-file-creation.asciidoc new file mode 100644 index 0000000000..70b420fb34 --- /dev/null +++ b/docs/detections/prebuilt-rules/rule-details/yum-package-manager-plugin-file-creation.asciidoc @@ -0,0 +1,127 @@ +[[yum-package-manager-plugin-file-creation]] +=== Yum Package Manager Plugin File Creation + +Detects file creation events in the plugin directories for the Yum package manager. In Linux, Yum (Yellowdog Updater, Modified) is a command-line utility used for handling packages on (by default) Fedora-based systems, providing functions for installing, updating, upgrading, and removing software along with managing package repositories. Attackers can backdoor Yum to gain persistence by injecting malicious code into plugins that Yum runs, thereby ensuring continued unauthorized access or control each time Yum is used for package management. + +*Rule type*: eql + +*Rule indices*: + +* logs-endpoint.events.file* + +*Severity*: low + +*Risk score*: 21 + +*Runs every*: 5m + +*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <>) + +*Maximum alerts per execution*: 100 + +*References*: + +* https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/linux/local/yum_package_manager_persistence.rb + +*Tags*: + +* Domain: Endpoint +* OS: Linux +* Use Case: Threat Detection +* Tactic: Persistence +* Tactic: Defense Evasion +* Data Source: Elastic Defend + +*Version*: 1 + +*Rule authors*: + +* Elastic + +*Rule license*: Elastic License v2 + + +==== Setup + + + +*Setup* + + +This rule requires data coming in from Elastic Defend. + + +*Elastic Defend Integration Setup* + +Elastic 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. + + +*Prerequisite Requirements:* + +- Fleet is required for Elastic Defend. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html[documentation]. + + +*The following steps should be executed in order to add the Elastic Defend integration on a Linux System:* + +- Go to the Kibana home page and click "Add integrations". +- In the query bar, search for "Elastic Defend" and select the integration to see more details about it. +- Click "Add Elastic Defend". +- Configure the integration name and optionally add a description. +- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads". +- 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. https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html[Helper guide]. +- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions" +- 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. +For more details on Elastic Agent configuration settings, refer to the https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html[helper guide]. +- Click "Save and Continue". +- 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. +For more details on Elastic Defend refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html[helper guide]. + + +==== Rule query + + +[source, js] +---------------------------------- +file where host.os.type == "linux" and event.action in ("rename", "creation") and +file.path : ("/usr/lib/yum-plugins/*", "/etc/yum/pluginconf.d/*") and not ( + process.executable in ( + "/bin/dockerd", "/usr/bin/dockerd", "/usr/sbin/dockerd", "/bin/microdnf", "/usr/bin/microdnf", "/bin/rpm", + "/usr/bin/rpm", "/bin/snapd", "/usr/bin/snapd", "/bin/yum", "/usr/bin/yum", "/bin/dnf", "/usr/bin/dnf", + "/bin/podman", "/usr/bin/podman", "/bin/dnf-automatic", "/usr/bin/dnf-automatic", "/sbin/apk", "/usr/sbin/apk", + "/usr/local/sbin/apk", "/bin/podman", "/usr/bin/podman", "/usr/bin/puppet", "/bin/puppet", + "/opt/puppetlabs/puppet/bin/puppet", "/usr/bin/chef-client", "/bin/chef-client", "/bin/autossl_check", + "/usr/bin/autossl_check", "/proc/self/exe", "/dev/fd/*", "/usr/lib/snapd/snapd", "/usr/local/bin/dockerd", + "/usr/libexec/netplan/generate" + ) or + process.name == "yumBackend.py" or + file.extension in ("swp", "swpx", "swx") or + process.executable : ( + "/nix/store/*", "/var/lib/dpkg/*", "/tmp/vmis.*", "/snap/*", "/dev/fd/*", "/usr/lib/*", "/usr/libexec/*", + "/etc/kernel/*" + ) or + process.executable == null or + (process.name == "sed" and file.name : "sed*") or + (process.name == "perl" and file.name : "e2scrub_all.tmp*") +) + +---------------------------------- + +*Framework*: MITRE ATT&CK^TM^ + +* Tactic: +** Name: Persistence +** ID: TA0003 +** Reference URL: https://attack.mitre.org/tactics/TA0003/ +* Technique: +** Name: Create or Modify System Process +** ID: T1543 +** Reference URL: https://attack.mitre.org/techniques/T1543/ +* Technique: +** Name: Hijack Execution Flow +** ID: T1574 +** Reference URL: https://attack.mitre.org/techniques/T1574/ +* Tactic: +** Name: Defense Evasion +** ID: TA0005 +** Reference URL: https://attack.mitre.org/tactics/TA0005/ diff --git a/docs/index.asciidoc b/docs/index.asciidoc index 1b63e55ff0..389a8af075 100644 --- a/docs/index.asciidoc +++ b/docs/index.asciidoc @@ -105,3 +105,5 @@ include::detections/prebuilt-rules/downloadable-packages/8-13-7/prebuilt-rules-8 include::detections/prebuilt-rules/downloadable-packages/8-13-8/prebuilt-rules-8-13-8-appendix.asciidoc[] include::detections/prebuilt-rules/downloadable-packages/8-13-9/prebuilt-rules-8-13-9-appendix.asciidoc[] + +include::detections/prebuilt-rules/downloadable-packages/8-13-10/prebuilt-rules-8-13-10-appendix.asciidoc[]