diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-12-4/prebuilt-rule-8-12-4-executable-masquerading-as-kernel-process.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-12-4/prebuilt-rule-8-12-4-executable-masquerading-as-kernel-process.asciidoc index e3e1551862..1b29299f07 100644 --- a/docs/detections/prebuilt-rules/downloadable-packages/8-12-4/prebuilt-rule-8-12-4-executable-masquerading-as-kernel-process.asciidoc +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-12-4/prebuilt-rule-8-12-4-executable-masquerading-as-kernel-process.asciidoc @@ -42,6 +42,38 @@ Monitors for kernel processes with associated process executable fields that are *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-12-4/prebuilt-rule-8-12-4-firsttime-seen-account-performing-dcsync.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-12-4/prebuilt-rule-8-12-4-firsttime-seen-account-performing-dcsync.asciidoc index 4ff1a5afcc..4453ac1448 100644 --- a/docs/detections/prebuilt-rules/downloadable-packages/8-12-4/prebuilt-rule-8-12-4-firsttime-seen-account-performing-dcsync.asciidoc +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-12-4/prebuilt-rule-8-12-4-firsttime-seen-account-performing-dcsync.asciidoc @@ -65,7 +65,7 @@ Active Directory data consists of objects that have properties, or attributes. E Adversaries can use the DCSync technique that uses Windows Domain Controller's API to simulate the replication process from a remote domain controller, compromising major credential material such as the Kerberos krbtgt keys that are used legitimately for creating tickets, but also for forging tickets by attackers. This attack requires some extended privileges to succeed (DS-Replication-Get-Changes and DS-Replication-Get-Changes-All), which are granted by default to members of the Administrators, Domain Admins, Enterprise Admins, and Domain Controllers groups. Privileged accounts can be abused to grant controlled objects the right to DCsync/Replicate. -More details can be found on [Threat Hunter Playbook](https://threathunterplaybook.com/library/windows/active_directory_replication.html?highlight=dcsync#directory-replication-services-auditing) and [The Hacker Recipes](https://www.thehacker.recipes/ad/movement/credentials/dumping/dcsync). +More details can be found on https://threathunterplaybook.com/library/windows/active_directory_replication.html?highlight=dcsync#directory-replication-services-auditing and https://www.thehacker.recipes/ad/movement/credentials/dumping/dcsync. This rule monitors for when a Windows Event ID 4662 (Operation was performed on an Active Directory object) with the access mask 0x100 (Control Access) and properties that contain at least one of the following or their equivalent Schema-Id-GUID (DS-Replication-Get-Changes, DS-Replication-Get-Changes-All, DS-Replication-Get-Changes-In-Filtered-Set) is seen in the environment for the first time in the last 15 days. @@ -93,6 +93,28 @@ This rule monitors for when a Windows Event ID 4662 (Operation was performed on - 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 + + +[source, markdown] +---------------------------------- + +The 'Audit Directory Service Access' 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 Access (Success,Failure) +``` + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-12-4/prebuilt-rule-8-12-4-potential-credential-access-via-dcsync.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-12-4/prebuilt-rule-8-12-4-potential-credential-access-via-dcsync.asciidoc index af2e6ed37c..a9241ca845 100644 --- a/docs/detections/prebuilt-rules/downloadable-packages/8-12-4/prebuilt-rule-8-12-4-potential-credential-access-via-dcsync.asciidoc +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-12-4/prebuilt-rule-8-12-4-potential-credential-access-via-dcsync.asciidoc @@ -65,9 +65,9 @@ Active Directory data consists of objects that have properties, or attributes. E Adversaries can use the DCSync technique that uses Windows Domain Controller's API to simulate the replication process from a remote domain controller, compromising major credential material such as the Kerberos krbtgt keys used legitimately for tickets creation, but also tickets forging by attackers. This attack requires some extended privileges to succeed (DS-Replication-Get-Changes and DS-Replication-Get-Changes-All), which are granted by default to members of the Administrators, Domain Admins, Enterprise Admins, and Domain Controllers groups. Privileged accounts can be abused to grant controlled objects the right to DCsync/Replicate. -More details can be found on [Threat Hunter Playbook](https://threathunterplaybook.com/library/windows/active_directory_replication.html?highlight=dcsync#directory-replication-services-auditing) and [The Hacker Recipes](https://www.thehacker.recipes/ad/movement/credentials/dumping/dcsync). +More details can be found on https://threathunterplaybook.com/library/windows/active_directory_replication.html?highlight=dcsync#directory-replication-services-auditing and https://www.thehacker.recipes/ad/movement/credentials/dumping/dcsync. -This rule monitors for Event ID 4662 (Operation was performed on an Active Directory object) and identifies events that use the access mask 0x100 (Control Access) and properties that contain at least one of the following or their equivalent Schema-Id-GUID (DS-Replication-Get-Changes, DS-Replication-Get-Changes-All, DS-Replication-Get-Changes-In-Filtered-Set). It also filters out events that use computer accounts and also Azure AD Connect MSOL accounts (more details [here](https://techcommunity.microsoft.com/t5/microsoft-defender-for-identity/ad-connect-msol-user-suspected-dcsync-attack/m-p/788028)). +This rule monitors for Event ID 4662 (Operation was performed on an Active Directory object) and identifies events that use the access mask 0x100 (Control Access) and properties that contain at least one of the following or their equivalent Schema-Id-GUID (DS-Replication-Get-Changes, DS-Replication-Get-Changes-All, DS-Replication-Get-Changes-In-Filtered-Set). It also filters out events that use computer accounts and also Azure AD Connect MSOL accounts (more details https://techcommunity.microsoft.com/t5/microsoft-defender-for-identity/ad-connect-msol-user-suspected-dcsync-attack/m-p/788028). #### Possible investigation steps @@ -93,6 +93,28 @@ This rule monitors for Event ID 4662 (Operation was performed on an Active Direc - 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 + + +[source, markdown] +---------------------------------- + +The 'Audit Directory Service Access' 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 Access (Success,Failure) +``` + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-12-4/prebuilt-rule-8-12-4-potential-modification-of-accessibility-binaries.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-12-4/prebuilt-rule-8-12-4-potential-modification-of-accessibility-binaries.asciidoc index 8d622820f2..42007bfa28 100644 --- a/docs/detections/prebuilt-rules/downloadable-packages/8-12-4/prebuilt-rule-8-12-4-potential-modification-of-accessibility-binaries.asciidoc +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-12-4/prebuilt-rule-8-12-4-potential-modification-of-accessibility-binaries.asciidoc @@ -56,12 +56,12 @@ Windows contains accessibility features that may be launched with a key combinat Adversaries may establish persistence and/or elevate privileges by executing malicious content triggered by accessibility features. Windows contains accessibility features that may be launched with a key combination before a user has logged in (ex: when the user is on the Windows logon screen). An adversary can modify the way these programs are launched to get a command prompt or backdoor without logging in to the system. -More details can be found [here](https://attack.mitre.org/techniques/T1546/008/). +More details can be found https://attack.mitre.org/techniques/T1546/008/. This rule looks for the execution of supposed accessibility binaries that don't match any of the accessibility features binaries' original file names, which is likely a custom binary deployed by the attacker. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps @@ -106,6 +106,20 @@ This rule looks for the execution of supposed accessibility binaries that don't +---------------------------------- + +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-12-4/prebuilt-rule-8-12-4-powershell-script-with-webcam-video-capture-capabilities.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-12-4/prebuilt-rule-8-12-4-powershell-script-with-webcam-video-capture-capabilities.asciidoc index 254c9d251a..b8f403bfc5 100644 --- a/docs/detections/prebuilt-rules/downloadable-packages/8-12-4/prebuilt-rule-8-12-4-powershell-script-with-webcam-video-capture-capabilities.asciidoc +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-12-4/prebuilt-rule-8-12-4-powershell-script-with-webcam-video-capture-capabilities.asciidoc @@ -41,6 +41,29 @@ Detects PowerShell scripts that can be used to record webcam video. Attackers ca *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- +The 'PowerShell Script Block Logging' logging policy must be enabled. +Steps to implement the logging policy with Advanced Audit Configuration: + +``` +Computer Configuration > +Administrative Templates > +Windows PowerShell > +Turn on PowerShell Script Block Logging (Enable) +``` + +Steps to implement the logging policy via registry: + +``` +reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1 +``` + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-12-4/prebuilt-rule-8-12-4-remote-scheduled-task-creation-via-rpc.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-12-4/prebuilt-rule-8-12-4-remote-scheduled-task-creation-via-rpc.asciidoc index dcf730ec3c..ff0890d383 100644 --- a/docs/detections/prebuilt-rules/downloadable-packages/8-12-4/prebuilt-rule-8-12-4-remote-scheduled-task-creation-via-rpc.asciidoc +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-12-4/prebuilt-rule-8-12-4-remote-scheduled-task-creation-via-rpc.asciidoc @@ -48,7 +48,7 @@ Identifies scheduled task creation from a remote source. This could be indicativ ### Investigating Remote Scheduled Task Creation -[Scheduled tasks](https://docs.microsoft.com/en-us/windows/win32/taskschd/about-the-task-scheduler) are a great mechanism for persistence and program execution. These features can be used remotely for a variety of legitimate reasons, but at the same time used by malware and adversaries. When investigating scheduled tasks that were set up remotely, one of the first steps should be to determine the original intent behind the configuration and to verify if the activity is tied to benign behavior such as software installation or any kind of network administrator work. One objective for these alerts is to understand the configured action within the scheduled task. This is captured within the registry event data for this rule and can be base64 decoded to view the value. +https://docs.microsoft.com/en-us/windows/win32/taskschd/about-the-task-scheduler are a great mechanism for persistence and program execution. These features can be used remotely for a variety of legitimate reasons, but at the same time used by malware and adversaries. When investigating scheduled tasks that were set up remotely, one of the first steps should be to determine the original intent behind the configuration and to verify if the activity is tied to benign behavior such as software installation or any kind of network administrator work. One objective for these alerts is to understand the configured action within the scheduled task. This is captured within the registry event data for this rule and can be base64 decoded to view the value. #### Possible investigation steps diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-12-4/prebuilt-rule-8-12-4-startup-or-run-key-registry-modification.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-12-4/prebuilt-rule-8-12-4-startup-or-run-key-registry-modification.asciidoc index 381fa08294..413815ec0c 100644 --- a/docs/detections/prebuilt-rules/downloadable-packages/8-12-4/prebuilt-rule-8-12-4-startup-or-run-key-registry-modification.asciidoc +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-12-4/prebuilt-rule-8-12-4-startup-or-run-key-registry-modification.asciidoc @@ -52,7 +52,7 @@ Identifies run key or startup key registry modifications. In order to survive re Adversaries may achieve persistence by referencing a program with a registry run key. Adding an entry to the run keys in the registry will cause the program referenced to be executed when a user logs in. These programs will executed under the context of the user and will have the account's permissions. This rule looks for this behavior by monitoring a range of registry run keys. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-12-4/prebuilt-rule-8-12-4-suspicious-apt-package-manager-execution.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-12-4/prebuilt-rule-8-12-4-suspicious-apt-package-manager-execution.asciidoc index 94c285e43d..f0ddbd2a50 100644 --- a/docs/detections/prebuilt-rules/downloadable-packages/8-12-4/prebuilt-rule-8-12-4-suspicious-apt-package-manager-execution.asciidoc +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-12-4/prebuilt-rule-8-12-4-suspicious-apt-package-manager-execution.asciidoc @@ -40,6 +40,38 @@ Detects suspicious process events executed by the APT package manager, potential *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-12-4/prebuilt-rule-8-12-4-suspicious-apt-package-manager-network-connection.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-12-4/prebuilt-rule-8-12-4-suspicious-apt-package-manager-network-connection.asciidoc index 2558c2c6e9..5f04b8a48d 100644 --- a/docs/detections/prebuilt-rules/downloadable-packages/8-12-4/prebuilt-rule-8-12-4-suspicious-apt-package-manager-network-connection.asciidoc +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-12-4/prebuilt-rule-8-12-4-suspicious-apt-package-manager-network-connection.asciidoc @@ -40,6 +40,38 @@ Detects suspicious network events executed by the APT package manager, potential *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-12-4/prebuilt-rule-8-12-4-suspicious-dynamic-linker-discovery-via-od.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-12-4/prebuilt-rule-8-12-4-suspicious-dynamic-linker-discovery-via-od.asciidoc index c2f2414ff8..0446a6f980 100644 --- a/docs/detections/prebuilt-rules/downloadable-packages/8-12-4/prebuilt-rule-8-12-4-suspicious-dynamic-linker-discovery-via-od.asciidoc +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-12-4/prebuilt-rule-8-12-4-suspicious-dynamic-linker-discovery-via-od.asciidoc @@ -42,6 +42,38 @@ Monitors for dynamic linker discovery via the od utility. od (octal dump) is a c *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-12-4/prebuilt-rule-8-12-4-suspicious-network-connection-via-systemd.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-12-4/prebuilt-rule-8-12-4-suspicious-network-connection-via-systemd.asciidoc index 4627ebc3cb..d2189e2732 100644 --- a/docs/detections/prebuilt-rules/downloadable-packages/8-12-4/prebuilt-rule-8-12-4-suspicious-network-connection-via-systemd.asciidoc +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-12-4/prebuilt-rule-8-12-4-suspicious-network-connection-via-systemd.asciidoc @@ -40,6 +40,38 @@ Detects suspicious network events executed by systemd, potentially indicating pe *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-12-4/prebuilt-rule-8-12-4-suspicious-passwd-file-event-action.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-12-4/prebuilt-rule-8-12-4-suspicious-passwd-file-event-action.asciidoc index 0362bdd982..296cd38aa4 100644 --- a/docs/detections/prebuilt-rules/downloadable-packages/8-12-4/prebuilt-rule-8-12-4-suspicious-passwd-file-event-action.asciidoc +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-12-4/prebuilt-rule-8-12-4-suspicious-passwd-file-event-action.asciidoc @@ -39,6 +39,59 @@ Monitors for the generation of a passwd password entry via openssl, followed by *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +This rule requires data coming in from Elastic Defend and Auditd Manager. + +### 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. + +#### 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. +- We suggest to select "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. +- 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. + +### 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" on a Linux 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. + +#### 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 the following additional audit rules are required to be added to the integration: + -- "-w /etc/passwd -p wa -k etcpasswd" + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/downloadable-packages/8-12-4/prebuilt-rule-8-12-4-suspicious-proc-maps-discovery.asciidoc b/docs/detections/prebuilt-rules/downloadable-packages/8-12-4/prebuilt-rule-8-12-4-suspicious-proc-maps-discovery.asciidoc index 2eef5c3840..ae923e3e6d 100644 --- a/docs/detections/prebuilt-rules/downloadable-packages/8-12-4/prebuilt-rule-8-12-4-suspicious-proc-maps-discovery.asciidoc +++ b/docs/detections/prebuilt-rules/downloadable-packages/8-12-4/prebuilt-rule-8-12-4-suspicious-proc-maps-discovery.asciidoc @@ -40,6 +40,38 @@ Monitors for /proc/*/maps file reads. The /proc/*/maps file in Linux provides a *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/prebuilt-rules-downloadable-updates.asciidoc b/docs/detections/prebuilt-rules/prebuilt-rules-downloadable-updates.asciidoc index 9b32f32741..907bb72824 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 +|<> | 09 Feb 2024 | 10 | 6 | +updating rules for 8.12.4 release package + + |<> | 08 Feb 2024 | 10 | 6 | This release includes new and tuned rules for Linux and Windows. New rules for Linux include detection for discovery, persistence, privilege escalation and defense evasion. @@ -48,3 +52,4 @@ include::downloadable-packages/8-12-1/prebuilt-rules-8-12-1-summary.asciidoc[lev include::downloadable-packages/8-12-2/prebuilt-rules-8-12-2-summary.asciidoc[leveloffset=+1] include::downloadable-packages/8-12-3/prebuilt-rules-8-12-3-summary.asciidoc[leveloffset=+1] include::downloadable-packages/8-12-4/prebuilt-rules-8-12-4-summary.asciidoc[leveloffset=+1] +include::downloadable-packages/8-12-4/prebuilt-rules-8-12-4-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 9644f52514..daed46557e 100644 --- a/docs/detections/prebuilt-rules/prebuilt-rules-reference.asciidoc +++ b/docs/detections/prebuilt-rules/prebuilt-rules-reference.asciidoc @@ -1706,7 +1706,7 @@ and their rule type is `machine_learning`. |<> |Detects when a user reports suspicious activity for their Okta account. These events should be investigated, as they can help security teams identify when an adversary is attempting to gain access to their network. |[Use Case: Identity and Access Audit], [Data Source: Okta], [Tactic: Initial Access] |8.10.0 |205 -|<> |Identifies the creation of the Antimalware Scan Interface (AMSI) DLL in an unusual location. This may indicate an attempt to bypass AMSI by loading a rogue AMSI module instead of the legit one. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Endgame], [Resources: Investigation Guide], [Data Source: Elastic Defend] |8.3.0 |7 +|<> |Identifies the creation of the Antimalware Scan Interface (AMSI) DLL in an unusual location. This may indicate an attempt to bypass AMSI by loading a rogue AMSI module instead of the legit one. |[Domain: Endpoint], [OS: Windows], [Use Case: Threat Detection], [Tactic: Defense Evasion], [Data Source: Elastic Endgame], [Resources: Investigation Guide], [Data Source: Elastic Defend] |8.3.0 |6 |<> |Identifies the execution of the Automator Workflows process followed by a network connection from it's XPC service. Adversaries may drop a custom workflow template that hosts malicious JavaScript for Automation (JXA) code as an alternative to using osascript. |[Domain: Endpoint], [OS: macOS], [Use Case: Threat Detection], [Tactic: Execution], [Data Source: Elastic Defend] |8.3.0 |105 diff --git a/docs/detections/prebuilt-rules/rule-details/abnormal-process-id-or-lock-file-created.asciidoc b/docs/detections/prebuilt-rules/rule-details/abnormal-process-id-or-lock-file-created.asciidoc index bdd1ac0ff8..974ccbe7fa 100644 --- a/docs/detections/prebuilt-rules/rule-details/abnormal-process-id-or-lock-file-created.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/abnormal-process-id-or-lock-file-created.asciidoc @@ -91,6 +91,38 @@ This rule identifies the creation of PID, lock, or reboot files in the /var/run/ - 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 + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/abnormally-large-dns-response.asciidoc b/docs/detections/prebuilt-rules/rule-details/abnormally-large-dns-response.asciidoc index 5d35480780..3ad6021c84 100644 --- a/docs/detections/prebuilt-rules/rule-details/abnormally-large-dns-response.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/abnormally-large-dns-response.asciidoc @@ -53,7 +53,7 @@ Specially crafted DNS requests can manipulate a known overflow vulnerability in ### Investigating Abnormally Large DNS Response -Detection alerts from this rule indicate possible anomalous activity around large byte DNS responses from a Windows DNS server. This detection rule was created based on activity represented in exploitation of vulnerability (CVE-2020-1350) also known as [SigRed](https://www.elastic.co/blog/detection-rules-for-sigred-vulnerability) during July 2020. +Detection alerts from this rule indicate possible anomalous activity around large byte DNS responses from a Windows DNS server. This detection rule was created based on activity represented in exploitation of vulnerability (CVE-2020-1350) also known as https://www.elastic.co/blog/detection-rules-for-sigred-vulnerability during July 2020. #### Possible investigation steps @@ -65,7 +65,7 @@ Detection alerts from this rule indicate possible anomalous activity around larg #### False positive analysis -- Based on this rule, which looks for a threshold of 60k bytes, it is possible for activity to be generated under 65k bytes and related to legitimate behavior. In packet capture files received by the [SANS Internet Storm Center](https://isc.sans.edu/forums/diary/PATCH+NOW+SIGRed+CVE20201350+Microsoft+DNS+Server+Vulnerability/26356/), byte responses were all observed as greater than 65k bytes. +- Based on this rule, which looks for a threshold of 60k bytes, it is possible for activity to be generated under 65k bytes and related to legitimate behavior. In packet capture files received by the https://isc.sans.edu/forums/diary/PATCH+NOW+SIGRed+CVE20201350+Microsoft+DNS+Server+Vulnerability/26356/, byte responses were all observed as greater than 65k bytes. - This activity can be triggered by compliance/vulnerability scanning or compromise assessment; it's important to determine the source of the activity and potentially allowlist the source host. ### Related rules @@ -76,9 +76,9 @@ Detection alerts from this rule indicate possible anomalous activity around larg ### Response and remediation - Initiate the incident response process based on the outcome of the triage. -- Ensure that you have deployed the latest Microsoft [Security Update](https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-1350) (Monthly Rollup or Security Only) and restarted the patched machines. If unable to patch immediately, Microsoft [released](https://support.microsoft.com/en-us/help/4569509/windows-dns-server-remote-code-execution-vulnerability) a registry-based workaround that doesn’t require a restart. This can be used as a temporary solution before the patch is applied. +- Ensure that you have deployed the latest Microsoft https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-1350 (Monthly Rollup or Security Only) and restarted the patched machines. If unable to patch immediately, Microsoft https://support.microsoft.com/en-us/help/4569509/windows-dns-server-remote-code-execution-vulnerability a registry-based workaround that doesn’t require a restart. This can be used as a temporary solution before the patch is applied. - Maintain backups of your critical systems to aid in quick recovery. -- Perform routine vulnerability scans of your systems, monitor [CISA advisories](https://us-cert.cisa.gov/ncas/current-activity) and patch identified vulnerabilities. +- Perform routine vulnerability scans of your systems, monitor https://us-cert.cisa.gov/ncas/current-activity and patch identified vulnerabilities. - If you observe a true positive, implement a remediation plan and monitor host-based artifacts for additional post-exploitation behavior. ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/access-of-stored-browser-credentials.asciidoc b/docs/detections/prebuilt-rules/rule-details/access-of-stored-browser-credentials.asciidoc index 8161f12cc7..c9d863dd68 100644 --- a/docs/detections/prebuilt-rules/rule-details/access-of-stored-browser-credentials.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/access-of-stored-browser-credentials.asciidoc @@ -40,6 +40,38 @@ Identifies the execution of a process with arguments pointing to known browser f *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### The following steps should be executed in order to add the Elastic Defend integration on a macOS 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, for MacOS it is recommended to select "Traditional Endpoints". +- 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/access-to-a-sensitive-ldap-attribute.asciidoc b/docs/detections/prebuilt-rules/rule-details/access-to-a-sensitive-ldap-attribute.asciidoc index 29796c3f10..92e54b89dd 100644 --- a/docs/detections/prebuilt-rules/rule-details/access-to-a-sensitive-ldap-attribute.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/access-to-a-sensitive-ldap-attribute.asciidoc @@ -46,6 +46,28 @@ Identify access to sensitive Active Directory object attributes that contains cr *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +The 'Audit Directory Service Access' 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 Access (Success,Failure) +``` + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/access-to-keychain-credentials-directories.asciidoc b/docs/detections/prebuilt-rules/rule-details/access-to-keychain-credentials-directories.asciidoc index 30065393df..42e9c521f5 100644 --- a/docs/detections/prebuilt-rules/rule-details/access-to-keychain-credentials-directories.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/access-to-keychain-credentials-directories.asciidoc @@ -41,6 +41,38 @@ Adversaries may collect the keychain storage data from a system to acquire crede *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### The following steps should be executed in order to add the Elastic Defend integration on a macOS 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, for MacOS it is recommended to select "Traditional Endpoints". +- 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/account-configured-with-never-expiring-password.asciidoc b/docs/detections/prebuilt-rules/rule-details/account-configured-with-never-expiring-password.asciidoc index aa3b93dc31..d2c36fe5fc 100644 --- a/docs/detections/prebuilt-rules/rule-details/account-configured-with-never-expiring-password.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/account-configured-with-never-expiring-password.asciidoc @@ -76,7 +76,7 @@ The setting is usually configured so a user account can act as a service account - Review the privileges assigned to the user to ensure that the least privilege principle is being followed. - Reset the password of the account and update its password settings. - Search for other occurrences on the domain. - - Using the [Active Directory PowerShell module](https://docs.microsoft.com/en-us/powershell/module/activedirectory/get-aduser): + - Using the https://docs.microsoft.com/en-us/powershell/module/activedirectory/get-aduser: - `get-aduser -filter { passwordNeverExpires -eq $true -and enabled -eq $true } | ft` - 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). diff --git a/docs/detections/prebuilt-rules/rule-details/account-discovery-command-via-system-account.asciidoc b/docs/detections/prebuilt-rules/rule-details/account-discovery-command-via-system-account.asciidoc index cfeb6c64bc..feb29da648 100644 --- a/docs/detections/prebuilt-rules/rule-details/account-discovery-command-via-system-account.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/account-discovery-command-via-system-account.asciidoc @@ -77,6 +77,20 @@ This rule looks for the execution of account discovery utilities using the SYSTE - Use the data collected through the analysis to investigate other machines affected in the environment. +---------------------------------- + +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/adding-hidden-file-attribute-via-attrib.asciidoc b/docs/detections/prebuilt-rules/rule-details/adding-hidden-file-attribute-via-attrib.asciidoc index 18960d343c..d530652d8c 100644 --- a/docs/detections/prebuilt-rules/rule-details/adding-hidden-file-attribute-via-attrib.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/adding-hidden-file-attribute-via-attrib.asciidoc @@ -61,7 +61,7 @@ Attackers can use this attribute to conceal tooling and malware to prevent admin This rule looks for the execution of the `attrib.exe` utility with a command line that indicates the modification of the `Hidden` attribute. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps diff --git a/docs/detections/prebuilt-rules/rule-details/adfind-command-activity.asciidoc b/docs/detections/prebuilt-rules/rule-details/adfind-command-activity.asciidoc index 2f4871c6ae..94398ecea5 100644 --- a/docs/detections/prebuilt-rules/rule-details/adfind-command-activity.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/adfind-command-activity.asciidoc @@ -60,7 +60,7 @@ This rule detects the Active Directory query tool, AdFind.exe. AdFind has legiti ### Investigating AdFind Command Activity -[AdFind](http://www.joeware.net/freetools/tools/adfind/) is a freely available command-line tool used to retrieve information from Active Directory (AD). Network discovery and enumeration tools like `AdFind` are useful to adversaries in the same ways they are effective for network administrators. This tool provides quick ability to scope AD person/computer objects and understand subnets and domain information. There are many [examples](https://thedfirreport.com/category/adfind/) of this tool being adopted by ransomware and criminal groups and used in compromises. +http://www.joeware.net/freetools/tools/adfind/ is a freely available command-line tool used to retrieve information from Active Directory (AD). Network discovery and enumeration tools like `AdFind` are useful to adversaries in the same ways they are effective for network administrators. This tool provides quick ability to scope AD person/computer objects and understand subnets and domain information. There are many https://thedfirreport.com/category/adfind/ of this tool being adopted by ransomware and criminal groups and used in compromises. #### Possible investigation steps @@ -92,6 +92,20 @@ This rule detects the Active Directory query tool, AdFind.exe. AdFind has legiti - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/administrator-privileges-assigned-to-an-okta-group.asciidoc b/docs/detections/prebuilt-rules/rule-details/administrator-privileges-assigned-to-an-okta-group.asciidoc index 505e0d3ba5..5fd99d568e 100644 --- a/docs/detections/prebuilt-rules/rule-details/administrator-privileges-assigned-to-an-okta-group.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/administrator-privileges-assigned-to-an-okta-group.asciidoc @@ -50,6 +50,14 @@ Detects when an administrator role is assigned to an Okta group. An adversary ma ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/administrator-role-assigned-to-an-okta-user.asciidoc b/docs/detections/prebuilt-rules/rule-details/administrator-role-assigned-to-an-okta-user.asciidoc index 7ab9be3397..de6a5c666e 100644 --- a/docs/detections/prebuilt-rules/rule-details/administrator-role-assigned-to-an-okta-user.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/administrator-role-assigned-to-an-okta-user.asciidoc @@ -50,6 +50,14 @@ Identifies when an administrator role is assigned to an Okta user. An adversary ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/adminsdholder-sdprop-exclusion-added.asciidoc b/docs/detections/prebuilt-rules/rule-details/adminsdholder-sdprop-exclusion-added.asciidoc index 6fbc41f40c..f0f98557fe 100644 --- a/docs/detections/prebuilt-rules/rule-details/adminsdholder-sdprop-exclusion-added.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/adminsdholder-sdprop-exclusion-added.asciidoc @@ -88,6 +88,34 @@ This rule matches changes of the dsHeuristics object where the 16th bit is set t - 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 + + +[source, markdown] +---------------------------------- + +The 'Audit Directory Service Changes' logging policy must be configured for (Success). +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) +``` + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/adobe-hijack-persistence.asciidoc b/docs/detections/prebuilt-rules/rule-details/adobe-hijack-persistence.asciidoc index e8b01c4848..f238d6f0f2 100644 --- a/docs/detections/prebuilt-rules/rule-details/adobe-hijack-persistence.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/adobe-hijack-persistence.asciidoc @@ -57,7 +57,7 @@ Detects writing executable files that will be automatically launched by Adobe on Attackers can replace the `RdrCEF.exe` executable with their own to maintain their access, which will be launched whenever Adobe Acrobat Reader is executed. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps @@ -101,6 +101,20 @@ Attackers can replace the `RdrCEF.exe` executable with their own to maintain the +---------------------------------- + +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query 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 5132d58f73..4a03a70636 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 @@ -54,7 +54,7 @@ Searching for abnormal Windows processes is a good methodology to find potential 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 {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps 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 95462ceaba..d12e7a5a6b 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 @@ -54,7 +54,7 @@ Searching for abnormal Windows processes is a good methodology to find potential 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 {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps diff --git a/docs/detections/prebuilt-rules/rule-details/apple-script-execution-followed-by-network-connection.asciidoc b/docs/detections/prebuilt-rules/rule-details/apple-script-execution-followed-by-network-connection.asciidoc index 91b5aa30b4..137e2d3402 100644 --- a/docs/detections/prebuilt-rules/rule-details/apple-script-execution-followed-by-network-connection.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/apple-script-execution-followed-by-network-connection.asciidoc @@ -42,6 +42,38 @@ Detects execution via the Apple script interpreter (osascript) followed by a net *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### The following steps should be executed in order to add the Elastic Defend integration on a macOS 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, for MacOS it is recommended to select "Traditional Endpoints". +- 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/apple-scripting-execution-with-administrator-privileges.asciidoc b/docs/detections/prebuilt-rules/rule-details/apple-scripting-execution-with-administrator-privileges.asciidoc index e4869515be..7dfe8ef021 100644 --- a/docs/detections/prebuilt-rules/rule-details/apple-scripting-execution-with-administrator-privileges.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/apple-scripting-execution-with-administrator-privileges.asciidoc @@ -41,6 +41,38 @@ Identifies execution of the Apple script interpreter (osascript) without a passw *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### The following steps should be executed in order to add the Elastic Defend integration on a macOS 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, for MacOS it is recommended to select "Traditional Endpoints". +- 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/application-added-to-google-workspace-domain.asciidoc b/docs/detections/prebuilt-rules/rule-details/application-added-to-google-workspace-domain.asciidoc index 9f0afe0333..21c6be9482 100644 --- a/docs/detections/prebuilt-rules/rule-details/application-added-to-google-workspace-domain.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/application-added-to-google-workspace-domain.asciidoc @@ -85,7 +85,7 @@ This rule checks for applications that were manually added to the Marketplace by - 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. - Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. -- Implement security best practices [outlined](https://support.google.com/a/answer/7587183) by Google. +- Implement security best practices https://support.google.com/a/answer/7587183 by Google. - Determine 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). @@ -101,6 +101,14 @@ This rule checks for applications that were manually added to the Marketplace by - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/application-removed-from-blocklist-in-google-workspace.asciidoc b/docs/detections/prebuilt-rules/rule-details/application-removed-from-blocklist-in-google-workspace.asciidoc index dda82739b6..4d9dcd091c 100644 --- a/docs/detections/prebuilt-rules/rule-details/application-removed-from-blocklist-in-google-workspace.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/application-removed-from-blocklist-in-google-workspace.asciidoc @@ -85,7 +85,7 @@ This rule identifies a Marketplace blocklist update that consists of a Google Wo - 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. - Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. -- Implement security best practices [outlined](https://support.google.com/a/answer/7587183) by Google. +- Implement security best practices https://support.google.com/a/answer/7587183 by Google. - Determine 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). @@ -101,6 +101,14 @@ This rule identifies a Marketplace blocklist update that consists of a Google Wo - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/attempt-to-clear-kernel-ring-buffer.asciidoc b/docs/detections/prebuilt-rules/rule-details/attempt-to-clear-kernel-ring-buffer.asciidoc index 4fe2f84c81..073ddb6784 100644 --- a/docs/detections/prebuilt-rules/rule-details/attempt-to-clear-kernel-ring-buffer.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/attempt-to-clear-kernel-ring-buffer.asciidoc @@ -38,6 +38,38 @@ Monitors for the deletion of the kernel ring buffer events through dmesg. Attack *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/attempt-to-create-okta-api-token.asciidoc b/docs/detections/prebuilt-rules/rule-details/attempt-to-create-okta-api-token.asciidoc index 018da007f4..e9025dc3ed 100644 --- a/docs/detections/prebuilt-rules/rule-details/attempt-to-create-okta-api-token.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/attempt-to-create-okta-api-token.asciidoc @@ -49,6 +49,14 @@ Detects attempts to create an Okta API token. An adversary may create an Okta AP ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/attempt-to-deactivate-an-okta-application.asciidoc b/docs/detections/prebuilt-rules/rule-details/attempt-to-deactivate-an-okta-application.asciidoc index 33e2435bfb..10bed9c8c4 100644 --- a/docs/detections/prebuilt-rules/rule-details/attempt-to-deactivate-an-okta-application.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/attempt-to-deactivate-an-okta-application.asciidoc @@ -75,6 +75,14 @@ This rule detects attempts to deactivate an Okta application. Unauthorized deact - If the deactivated application was crucial for business operations, coordinate with the relevant team to reactivate it and minimize the impact. ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/attempt-to-deactivate-an-okta-network-zone.asciidoc b/docs/detections/prebuilt-rules/rule-details/attempt-to-deactivate-an-okta-network-zone.asciidoc index a7df47b956..a28bca7db7 100644 --- a/docs/detections/prebuilt-rules/rule-details/attempt-to-deactivate-an-okta-network-zone.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/attempt-to-deactivate-an-okta-network-zone.asciidoc @@ -78,6 +78,14 @@ The Okta network zones can be configured to restrict or limit access to a networ - Communicate and train the employees about the importance of following proper procedures for modifying network zone settings. ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/attempt-to-deactivate-an-okta-policy-rule.asciidoc b/docs/detections/prebuilt-rules/rule-details/attempt-to-deactivate-an-okta-policy-rule.asciidoc index 37ed4ddd5c..5f2e5ce175 100644 --- a/docs/detections/prebuilt-rules/rule-details/attempt-to-deactivate-an-okta-policy-rule.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/attempt-to-deactivate-an-okta-policy-rule.asciidoc @@ -81,10 +81,18 @@ This rule detects attempts to deactivate a rule within an Okta policy, which cou - Assess the criticality of affected services and servers. - Work with your IT team to minimize the impact on users and maintain business continuity. - If multiple accounts are affected, consider a broader reset or audit of MFA tokens. -- Implement security best practices [outlined](https://www.okta.com/blog/2019/10/9-admin-best-practices-to-keep-your-org-secure/) by Okta. +- Implement security best practices https://www.okta.com/blog/2019/10/9-admin-best-practices-to-keep-your-org-secure/ by Okta. - 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 + + +[source, markdown] +---------------------------------- +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/attempt-to-deactivate-an-okta-policy.asciidoc b/docs/detections/prebuilt-rules/rule-details/attempt-to-deactivate-an-okta-policy.asciidoc index fa96944dcd..c8ed0143df 100644 --- a/docs/detections/prebuilt-rules/rule-details/attempt-to-deactivate-an-okta-policy.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/attempt-to-deactivate-an-okta-policy.asciidoc @@ -81,10 +81,18 @@ This rule is designed to detect attempts to deactivate an Okta policy, which cou - Assess the criticality of affected services and servers. - Work with your IT team to minimize the impact on users and maintain business continuity. - If multiple accounts are affected, consider a broader reset or audit of MFA tokens. -- Implement security best practices [outlined](https://www.okta.com/blog/2019/10/9-admin-best-practices-to-keep-your-org-secure/) by Okta. +- Implement security best practices https://www.okta.com/blog/2019/10/9-admin-best-practices-to-keep-your-org-secure/ by Okta. - 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 + + +[source, markdown] +---------------------------------- +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/attempt-to-delete-an-okta-application.asciidoc b/docs/detections/prebuilt-rules/rule-details/attempt-to-delete-an-okta-application.asciidoc index 7c839d306b..ca0d64015e 100644 --- a/docs/detections/prebuilt-rules/rule-details/attempt-to-delete-an-okta-application.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/attempt-to-delete-an-okta-application.asciidoc @@ -49,6 +49,14 @@ Detects attempts to delete an Okta application. An adversary may attempt to modi ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/attempt-to-delete-an-okta-network-zone.asciidoc b/docs/detections/prebuilt-rules/rule-details/attempt-to-delete-an-okta-network-zone.asciidoc index 45b842e9dc..fc8c030c1e 100644 --- a/docs/detections/prebuilt-rules/rule-details/attempt-to-delete-an-okta-network-zone.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/attempt-to-delete-an-okta-network-zone.asciidoc @@ -78,6 +78,14 @@ Okta network zones can be configured to limit or restrict access to a network ba - Communicate and train the employees about the importance of following proper procedures for modifying network zone settings. ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/attempt-to-delete-an-okta-policy-rule.asciidoc b/docs/detections/prebuilt-rules/rule-details/attempt-to-delete-an-okta-policy-rule.asciidoc index e3335aabdd..d3cae1be3b 100644 --- a/docs/detections/prebuilt-rules/rule-details/attempt-to-delete-an-okta-policy-rule.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/attempt-to-delete-an-okta-policy-rule.asciidoc @@ -81,10 +81,18 @@ This rule detects attempts to delete an Okta policy rule, which could indicate a - Assess the criticality of affected services and servers. - Work with your IT team to minimize the impact on users and maintain business continuity. - If multiple accounts are affected, consider a broader reset or audit of MFA tokens. -- Implement security best practices [outlined](https://www.okta.com/blog/2019/10/9-admin-best-practices-to-keep-your-org-secure/) by Okta. +- Implement security best practices https://www.okta.com/blog/2019/10/9-admin-best-practices-to-keep-your-org-secure/ by Okta. - 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 + + +[source, markdown] +---------------------------------- +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/attempt-to-delete-an-okta-policy.asciidoc b/docs/detections/prebuilt-rules/rule-details/attempt-to-delete-an-okta-policy.asciidoc index 5d7cf3fb7d..5a9d24c86e 100644 --- a/docs/detections/prebuilt-rules/rule-details/attempt-to-delete-an-okta-policy.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/attempt-to-delete-an-okta-policy.asciidoc @@ -81,10 +81,18 @@ This rule detects attempts to delete an Okta policy, which could be indicative o - Assess the criticality of affected services and servers. - Work with your IT team to minimize the impact on users and maintain business continuity. - If multiple accounts are affected, consider a broader reset or audit of MFA tokens. -- Implement security best practices [outlined](https://www.okta.com/blog/2019/10/9-admin-best-practices-to-keep-your-org-secure/) by Okta. +- Implement security best practices https://www.okta.com/blog/2019/10/9-admin-best-practices-to-keep-your-org-secure/ by Okta. - 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 + + +[source, markdown] +---------------------------------- +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/attempt-to-disable-gatekeeper.asciidoc b/docs/detections/prebuilt-rules/rule-details/attempt-to-disable-gatekeeper.asciidoc index 42508a7d3a..f73a1bb1f2 100644 --- a/docs/detections/prebuilt-rules/rule-details/attempt-to-disable-gatekeeper.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/attempt-to-disable-gatekeeper.asciidoc @@ -41,6 +41,38 @@ Detects attempts to disable Gatekeeper on macOS. Gatekeeper is a security featur *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### The following steps should be executed in order to add the Elastic Defend integration on a macOS 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, for MacOS it is recommended to select "Traditional Endpoints". +- 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/attempt-to-disable-iptables-or-firewall.asciidoc b/docs/detections/prebuilt-rules/rule-details/attempt-to-disable-iptables-or-firewall.asciidoc index 661519ee88..91360c9628 100644 --- a/docs/detections/prebuilt-rules/rule-details/attempt-to-disable-iptables-or-firewall.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/attempt-to-disable-iptables-or-firewall.asciidoc @@ -38,6 +38,38 @@ Adversaries may attempt to disable the iptables or firewall service in an attemp *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/attempt-to-disable-syslog-service.asciidoc b/docs/detections/prebuilt-rules/rule-details/attempt-to-disable-syslog-service.asciidoc index fbf6b7bf88..e81f5837fd 100644 --- a/docs/detections/prebuilt-rules/rule-details/attempt-to-disable-syslog-service.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/attempt-to-disable-syslog-service.asciidoc @@ -41,6 +41,50 @@ Adversaries may attempt to disable the syslog service in an attempt to an attemp *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Auditbeat + +### 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. + +#### 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. +- 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. +- 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. + +### Auditbeat Setup +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + +#### The following steps should be executed in order to add the Auditbeat on a Linux System: +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/attempt-to-enable-the-root-account.asciidoc b/docs/detections/prebuilt-rules/rule-details/attempt-to-enable-the-root-account.asciidoc index de448d3e76..82d65d211b 100644 --- a/docs/detections/prebuilt-rules/rule-details/attempt-to-enable-the-root-account.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/attempt-to-enable-the-root-account.asciidoc @@ -40,6 +40,38 @@ Identifies attempts to enable the root account using the dsenableroot command. T *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### The following steps should be executed in order to add the Elastic Defend integration on a macOS 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, for MacOS it is recommended to select "Traditional Endpoints". +- 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/attempt-to-install-root-certificate.asciidoc b/docs/detections/prebuilt-rules/rule-details/attempt-to-install-root-certificate.asciidoc index 490808d4e6..97e9fa600c 100644 --- a/docs/detections/prebuilt-rules/rule-details/attempt-to-install-root-certificate.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/attempt-to-install-root-certificate.asciidoc @@ -40,6 +40,38 @@ Adversaries may install a root certificate on a compromised system to avoid warn *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### The following steps should be executed in order to add the Elastic Defend integration on a macOS 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, for MacOS it is recommended to select "Traditional Endpoints". +- 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/attempt-to-modify-an-okta-application.asciidoc b/docs/detections/prebuilt-rules/rule-details/attempt-to-modify-an-okta-application.asciidoc index 574efdc398..ba08e36fe0 100644 --- a/docs/detections/prebuilt-rules/rule-details/attempt-to-modify-an-okta-application.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/attempt-to-modify-an-okta-application.asciidoc @@ -50,6 +50,14 @@ Detects attempts to modify an Okta application. An adversary may attempt to modi ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/attempt-to-modify-an-okta-network-zone.asciidoc b/docs/detections/prebuilt-rules/rule-details/attempt-to-modify-an-okta-network-zone.asciidoc index 3502233fad..c3ac1c72ec 100644 --- a/docs/detections/prebuilt-rules/rule-details/attempt-to-modify-an-okta-network-zone.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/attempt-to-modify-an-okta-network-zone.asciidoc @@ -80,10 +80,18 @@ The modification of an Okta network zone is a critical event as it could potenti - Assess the criticality of affected services and servers. - Work with your IT team to minimize the impact on users and maintain business continuity. - If multiple accounts are affected, consider a broader reset or audit of MFA tokens. -- Implement security best practices [outlined](https://www.okta.com/blog/2019/10/9-admin-best-practices-to-keep-your-org-secure/) by Okta. +- Implement security best practices https://www.okta.com/blog/2019/10/9-admin-best-practices-to-keep-your-org-secure/ by Okta. - 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 + + +[source, markdown] +---------------------------------- +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/attempt-to-modify-an-okta-policy-rule.asciidoc b/docs/detections/prebuilt-rules/rule-details/attempt-to-modify-an-okta-policy-rule.asciidoc index d07bfb897c..bd41812737 100644 --- a/docs/detections/prebuilt-rules/rule-details/attempt-to-modify-an-okta-policy-rule.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/attempt-to-modify-an-okta-policy-rule.asciidoc @@ -79,10 +79,18 @@ The modification of an Okta policy rule can be an indication of malicious activi - Assess the criticality of affected services and servers. - Work with your IT team to minimize the impact on users and maintain business continuity. - If multiple accounts are affected, consider a broader reset or audit of MFA tokens. -- Implement security best practices [outlined](https://www.okta.com/blog/2019/10/9-admin-best-practices-to-keep-your-org-secure/) by Okta. +- Implement security best practices https://www.okta.com/blog/2019/10/9-admin-best-practices-to-keep-your-org-secure/ by Okta. - 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 + + +[source, markdown] +---------------------------------- +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/attempt-to-modify-an-okta-policy.asciidoc b/docs/detections/prebuilt-rules/rule-details/attempt-to-modify-an-okta-policy.asciidoc index 67b47c287b..e6cd507404 100644 --- a/docs/detections/prebuilt-rules/rule-details/attempt-to-modify-an-okta-policy.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/attempt-to-modify-an-okta-policy.asciidoc @@ -73,6 +73,14 @@ Modifications to Okta policies may indicate attempts to weaken an organization's - Consider a security review of your Okta policies and rules to ensure they follow security best practices. ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/attempt-to-mount-smb-share-via-command-line.asciidoc b/docs/detections/prebuilt-rules/rule-details/attempt-to-mount-smb-share-via-command-line.asciidoc index d6674fe476..73226562b7 100644 --- a/docs/detections/prebuilt-rules/rule-details/attempt-to-mount-smb-share-via-command-line.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/attempt-to-mount-smb-share-via-command-line.asciidoc @@ -41,6 +41,38 @@ Identifies the execution of macOS built-in commands to mount a Server Message Bl *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### The following steps should be executed in order to add the Elastic Defend integration on a macOS 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, for MacOS it is recommended to select "Traditional Endpoints". +- 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/attempt-to-remove-file-quarantine-attribute.asciidoc b/docs/detections/prebuilt-rules/rule-details/attempt-to-remove-file-quarantine-attribute.asciidoc index a1702a0376..9f9f7ce6bc 100644 --- a/docs/detections/prebuilt-rules/rule-details/attempt-to-remove-file-quarantine-attribute.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/attempt-to-remove-file-quarantine-attribute.asciidoc @@ -41,6 +41,38 @@ Identifies a potential Gatekeeper bypass. In macOS, when applications or program *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### The following steps should be executed in order to add the Elastic Defend integration on a macOS 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, for MacOS it is recommended to select "Traditional Endpoints". +- 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/attempt-to-reset-mfa-factors-for-an-okta-user-account.asciidoc b/docs/detections/prebuilt-rules/rule-details/attempt-to-reset-mfa-factors-for-an-okta-user-account.asciidoc index d8145ce50e..61a58e1579 100644 --- a/docs/detections/prebuilt-rules/rule-details/attempt-to-reset-mfa-factors-for-an-okta-user-account.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/attempt-to-reset-mfa-factors-for-an-okta-user-account.asciidoc @@ -49,6 +49,14 @@ Detects attempts to reset an Okta user's enrolled multi-factor authentication (M ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/attempt-to-revoke-okta-api-token.asciidoc b/docs/detections/prebuilt-rules/rule-details/attempt-to-revoke-okta-api-token.asciidoc index 188fcadad4..0524622007 100644 --- a/docs/detections/prebuilt-rules/rule-details/attempt-to-revoke-okta-api-token.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/attempt-to-revoke-okta-api-token.asciidoc @@ -71,6 +71,14 @@ The rule alerts when attempts are made to revoke an Okta API token. The API toke - If the revoked token was used for critical integrations, coordinate with the relevant team to minimize the impact. ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/attempt-to-unload-elastic-endpoint-security-kernel-extension.asciidoc b/docs/detections/prebuilt-rules/rule-details/attempt-to-unload-elastic-endpoint-security-kernel-extension.asciidoc index 227025a5ac..a6fb8029c0 100644 --- a/docs/detections/prebuilt-rules/rule-details/attempt-to-unload-elastic-endpoint-security-kernel-extension.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/attempt-to-unload-elastic-endpoint-security-kernel-extension.asciidoc @@ -38,6 +38,38 @@ Identifies attempts to unload the Elastic Endpoint Security kernel extension via *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### The following steps should be executed in order to add the Elastic Defend integration on a macOS 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, for MacOS it is recommended to select "Traditional Endpoints". +- 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/attempted-bypass-of-okta-mfa.asciidoc b/docs/detections/prebuilt-rules/rule-details/attempted-bypass-of-okta-mfa.asciidoc index a827aebf32..bbddd6b7aa 100644 --- a/docs/detections/prebuilt-rules/rule-details/attempted-bypass-of-okta-mfa.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/attempted-bypass-of-okta-mfa.asciidoc @@ -80,10 +80,18 @@ This rule detects attempts to bypass Okta MFA. It might indicate a serious attem - Assess the criticality of affected services and servers. - Work with your IT team to minimize the impact on users and maintain business continuity. - If multiple accounts are affected, consider a broader reset or audit of MFA tokens. -- Implement security best practices [outlined](https://www.okta.com/blog/2019/10/9-admin-best-practices-to-keep-your-org-secure/) by Okta. +- Implement security best practices https://www.okta.com/blog/2019/10/9-admin-best-practices-to-keep-your-org-secure/ by Okta. - 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 + + +[source, markdown] +---------------------------------- +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/attempts-to-brute-force-a-microsoft-365-user-account.asciidoc b/docs/detections/prebuilt-rules/rule-details/attempts-to-brute-force-a-microsoft-365-user-account.asciidoc index ae622e98fd..4f9f2c665f 100644 --- a/docs/detections/prebuilt-rules/rule-details/attempts-to-brute-force-a-microsoft-365-user-account.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/attempts-to-brute-force-a-microsoft-365-user-account.asciidoc @@ -50,6 +50,14 @@ Identifies attempts to brute force a Microsoft 365 user account. An adversary ma ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/attempts-to-brute-force-an-okta-user-account.asciidoc b/docs/detections/prebuilt-rules/rule-details/attempts-to-brute-force-an-okta-user-account.asciidoc index c837806e1f..e4a5e3eaed 100644 --- a/docs/detections/prebuilt-rules/rule-details/attempts-to-brute-force-an-okta-user-account.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/attempts-to-brute-force-an-okta-user-account.asciidoc @@ -83,6 +83,14 @@ This rule fires when an Okta user account has been locked out 3 times within a 3 - Check if the compromised account was used to access or alter any sensitive data or systems. ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/authorization-plugin-modification.asciidoc b/docs/detections/prebuilt-rules/rule-details/authorization-plugin-modification.asciidoc index 39fbb16f25..b082a57942 100644 --- a/docs/detections/prebuilt-rules/rule-details/authorization-plugin-modification.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/authorization-plugin-modification.asciidoc @@ -41,6 +41,38 @@ Authorization plugins are used to extend the authorization services API and impl *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### The following steps should be executed in order to add the Elastic Defend integration on a macOS 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, for MacOS it is recommended to select "Traditional Endpoints". +- 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/aws-cloudtrail-log-created.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-cloudtrail-log-created.asciidoc index a07323325e..53c83356a8 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-cloudtrail-log-created.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-cloudtrail-log-created.asciidoc @@ -50,6 +50,14 @@ Identifies the creation of an AWS log trail that specifies the settings for deli ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/aws-cloudtrail-log-deleted.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-cloudtrail-log-deleted.asciidoc index 1101846b83..e37c4730c5 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-cloudtrail-log-deleted.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-cloudtrail-log-deleted.asciidoc @@ -87,12 +87,20 @@ This rule identifies the deletion of an AWS log trail using the API `DeleteTrail - 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 [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS. +- Implement security best practices https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/ 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 + + +[source, markdown] +---------------------------------- +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/aws-cloudtrail-log-suspended.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-cloudtrail-log-suspended.asciidoc index 180831ac5b..761d4c8884 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-cloudtrail-log-suspended.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-cloudtrail-log-suspended.asciidoc @@ -87,12 +87,20 @@ This rule identifies the suspension of an AWS log trail using the API `StopLoggi - 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 [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS. +- Implement security best practices https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/ 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 + + +[source, markdown] +---------------------------------- +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/aws-cloudtrail-log-updated.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-cloudtrail-log-updated.asciidoc index 48da7776ca..fa49a53519 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-cloudtrail-log-updated.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-cloudtrail-log-updated.asciidoc @@ -87,12 +87,20 @@ This rule identifies a modification on CloudTrail settings using the API `Update - 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 [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS. +- Implement security best practices https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/ 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 + + +[source, markdown] +---------------------------------- +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/aws-cloudwatch-alarm-deletion.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-cloudwatch-alarm-deletion.asciidoc index 78c56cf933..3b5b9d479e 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-cloudwatch-alarm-deletion.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-cloudwatch-alarm-deletion.asciidoc @@ -92,12 +92,20 @@ tracks and evade security defenses. - 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 [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS. +- Implement security best practices https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/ 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 + + +[source, markdown] +---------------------------------- +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/aws-cloudwatch-log-group-deletion.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-cloudwatch-log-group-deletion.asciidoc index f1057330e7..a633552d21 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-cloudwatch-log-group-deletion.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-cloudwatch-log-group-deletion.asciidoc @@ -89,12 +89,20 @@ This rule looks for the deletion of a log group using the API `DeleteLogGroup` a - 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 [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS. +- Implement security best practices https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/ 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 + + +[source, markdown] +---------------------------------- +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/aws-cloudwatch-log-stream-deletion.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-cloudwatch-log-stream-deletion.asciidoc index 7c5151dfbb..9d718f77bc 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-cloudwatch-log-stream-deletion.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-cloudwatch-log-stream-deletion.asciidoc @@ -89,12 +89,20 @@ This rule looks for the deletion of a log stream using the API `DeleteLogStream` - 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 [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS. +- Implement security best practices https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/ 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 + + +[source, markdown] +---------------------------------- +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/aws-config-resource-deletion.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-config-resource-deletion.asciidoc index 4fb0f0813b..756d60f53e 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-config-resource-deletion.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-config-resource-deletion.asciidoc @@ -87,12 +87,20 @@ This rule looks for the deletion of AWS Config resources using various API actio - 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 [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS. +- Implement security best practices https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/ 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 + + +[source, markdown] +---------------------------------- +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/aws-configuration-recorder-stopped.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-configuration-recorder-stopped.asciidoc index c40ff55ddd..7a7b9177a8 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-configuration-recorder-stopped.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-configuration-recorder-stopped.asciidoc @@ -49,6 +49,14 @@ Identifies an AWS configuration change to stop recording a designated set of res ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/aws-deletion-of-rds-instance-or-cluster.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-deletion-of-rds-instance-or-cluster.asciidoc index 31ede4dc18..4abd34477f 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-deletion-of-rds-instance-or-cluster.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-deletion-of-rds-instance-or-cluster.asciidoc @@ -54,6 +54,14 @@ Identifies the deletion of an Amazon Relational Database Service (RDS) Aurora da ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/aws-ec2-encryption-disabled.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-ec2-encryption-disabled.asciidoc index abb6999466..9976fbe723 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-ec2-encryption-disabled.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-ec2-encryption-disabled.asciidoc @@ -50,6 +50,14 @@ Identifies disabling of Amazon Elastic Block Store (EBS) encryption by default i ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/aws-ec2-full-network-packet-capture-detected.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-ec2-full-network-packet-capture-detected.asciidoc index 797aa13b14..1024bc8eef 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-ec2-full-network-packet-capture-detected.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-ec2-full-network-packet-capture-detected.asciidoc @@ -52,6 +52,14 @@ Identifies potential Traffic Mirroring in an Amazon Elastic Compute Cloud (EC2) ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/aws-ec2-network-access-control-list-creation.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-ec2-network-access-control-list-creation.asciidoc index cb045eb6d5..52da9c9771 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-ec2-network-access-control-list-creation.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-ec2-network-access-control-list-creation.asciidoc @@ -52,6 +52,14 @@ Identifies the creation of an AWS Elastic Compute Cloud (EC2) network access con ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/aws-ec2-network-access-control-list-deletion.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-ec2-network-access-control-list-deletion.asciidoc index c3f23b0bec..6fa9bfa6a6 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-ec2-network-access-control-list-deletion.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-ec2-network-access-control-list-deletion.asciidoc @@ -52,6 +52,14 @@ Identifies the deletion of an Amazon Elastic Compute Cloud (EC2) network access ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/aws-ec2-snapshot-activity.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-ec2-snapshot-activity.asciidoc index 2efd8eb714..8242d5dd26 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-ec2-snapshot-activity.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-ec2-snapshot-activity.asciidoc @@ -89,12 +89,20 @@ This rule looks for the modification of snapshot attributes using the API `Modif - 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 [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS. +- Implement security best practices https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/ 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 + + +[source, markdown] +---------------------------------- +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/aws-ec2-vm-export-failure.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-ec2-vm-export-failure.asciidoc index cc36bf6ad5..4e4aef0984 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-ec2-vm-export-failure.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-ec2-vm-export-failure.asciidoc @@ -51,6 +51,14 @@ Identifies an attempt to export an AWS EC2 instance. A virtual machine (VM) expo ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/aws-efs-file-system-or-mount-deleted.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-efs-file-system-or-mount-deleted.asciidoc index e5b98eb398..666414b919 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-efs-file-system-or-mount-deleted.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-efs-file-system-or-mount-deleted.asciidoc @@ -49,6 +49,14 @@ Detects when an EFS File System or Mount is deleted. An adversary could break an ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/aws-elasticache-security-group-created.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-elasticache-security-group-created.asciidoc index 8ba3d86c1e..3d403a7959 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-elasticache-security-group-created.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-elasticache-security-group-created.asciidoc @@ -48,6 +48,14 @@ Identifies when an ElastiCache security group has been created. ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/aws-elasticache-security-group-modified-or-deleted.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-elasticache-security-group-modified-or-deleted.asciidoc index 2a24a6de94..257b90d8db 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-elasticache-security-group-modified-or-deleted.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-elasticache-security-group-modified-or-deleted.asciidoc @@ -48,6 +48,14 @@ Identifies when an ElastiCache security group has been modified or deleted. ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/aws-eventbridge-rule-disabled-or-deleted.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-eventbridge-rule-disabled-or-deleted.asciidoc index 169ded4b69..0e3123e3f2 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-eventbridge-rule-disabled-or-deleted.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-eventbridge-rule-disabled-or-deleted.asciidoc @@ -49,6 +49,14 @@ Identifies when a user has disabled or deleted an EventBridge rule. This activit ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/aws-execution-via-system-manager.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-execution-via-system-manager.asciidoc index 5a16856614..a95055388c 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-execution-via-system-manager.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-execution-via-system-manager.asciidoc @@ -88,12 +88,20 @@ This rule looks for the execution of commands and scripts using System Manager. - 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 [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS. +- Implement security best practices https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/ 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 + + +[source, markdown] +---------------------------------- +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/aws-guardduty-detector-deletion.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-guardduty-detector-deletion.asciidoc index 27eb953909..49032e64ee 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-guardduty-detector-deletion.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-guardduty-detector-deletion.asciidoc @@ -49,6 +49,14 @@ Identifies the deletion of an Amazon GuardDuty detector. Upon deletion, GuardDut ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/aws-iam-assume-role-policy-update.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-iam-assume-role-policy-update.asciidoc index 5837358d87..86bad30e6c 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-iam-assume-role-policy-update.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-iam-assume-role-policy-update.asciidoc @@ -77,16 +77,24 @@ The role trust policy is a JSON document in which you define the principals you - 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. -- Use AWS [policy versioning](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-versioning.html) to restore the trust policy to the desired state. +- Use AWS https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-versioning.html to restore the trust policy to the desired state. - 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 [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS. +- Implement security best practices https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/ by AWS. - Determine 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 + + +[source, markdown] +---------------------------------- +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/aws-iam-brute-force-of-assume-role-policy.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-iam-brute-force-of-assume-role-policy.asciidoc index 9824af60e1..172d1828a9 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-iam-brute-force-of-assume-role-policy.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-iam-brute-force-of-assume-role-policy.asciidoc @@ -86,11 +86,19 @@ Attackers may attempt to enumerate IAM roles in order to determine if a role exi - 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 [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS. +- Implement security best practices https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/ by AWS. - Determine 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 + + +[source, markdown] +---------------------------------- +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/aws-iam-deactivation-of-mfa-device.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-iam-deactivation-of-mfa-device.asciidoc index b393f6b4f2..92f0527f15 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-iam-deactivation-of-mfa-device.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-iam-deactivation-of-mfa-device.asciidoc @@ -54,7 +54,7 @@ Identifies the deactivation of a specified multi-factor authentication (MFA) dev Multi-factor authentication (MFA) in AWS is a simple best practice that adds an extra layer of protection on top of your user name and password. With MFA enabled, when a user signs in to an AWS Management Console, they will be prompted for their user name and password (the first factor—what they know), as well as for an authentication code from their AWS MFA device (the second factor—what they have). Taken together, these multiple factors provide increased security for your AWS account settings and resources. -For more information about using MFA in AWS, access the [official documentation](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html). +For more information about using MFA in AWS, access the https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html. This rule looks for the deactivation or deletion of AWS MFA devices. These modifications weaken account security and can lead to the compromise of accounts and other assets. @@ -83,11 +83,19 @@ This rule looks for the deactivation or deletion of AWS MFA devices. These modif - 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. - Reactivate multi-factor authentication for the user. - Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. -- Implement security best practices [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS. +- Implement security best practices https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/ by AWS. - Determine 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 + + +[source, markdown] +---------------------------------- +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/aws-iam-group-creation.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-iam-group-creation.asciidoc index 1e9af572ef..9604f0e226 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-iam-group-creation.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-iam-group-creation.asciidoc @@ -50,6 +50,14 @@ Identifies the creation of a group in AWS Identity and Access Management (IAM). ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/aws-iam-group-deletion.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-iam-group-deletion.asciidoc index 68b0e124bc..09e988d5a8 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-iam-group-deletion.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-iam-group-deletion.asciidoc @@ -49,6 +49,14 @@ Identifies the deletion of a specified AWS Identity and Access Management (IAM) ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/aws-iam-password-recovery-requested.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-iam-password-recovery-requested.asciidoc index 5a93c59a62..40ab571b7a 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-iam-password-recovery-requested.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-iam-password-recovery-requested.asciidoc @@ -49,6 +49,14 @@ Identifies AWS IAM password recovery requests. An adversary may attempt to gain ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/aws-iam-user-addition-to-group.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-iam-user-addition-to-group.asciidoc index 79c3de8735..3909d8cf26 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-iam-user-addition-to-group.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-iam-user-addition-to-group.asciidoc @@ -82,11 +82,19 @@ This rule looks for the addition of users to a specified user group. - 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 [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS. +- Implement security best practices https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/ by AWS. - Determine 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 + + +[source, markdown] +---------------------------------- +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/aws-kms-customer-managed-key-disabled-or-scheduled-for-deletion.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-kms-customer-managed-key-disabled-or-scheduled-for-deletion.asciidoc index 8c9865e19e..2a85b9f0a9 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-kms-customer-managed-key-disabled-or-scheduled-for-deletion.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-kms-customer-managed-key-disabled-or-scheduled-for-deletion.asciidoc @@ -50,6 +50,14 @@ Identifies attempts to disable or schedule the deletion of an AWS KMS Customer M ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/aws-management-console-brute-force-of-root-user-identity.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-management-console-brute-force-of-root-user-identity.asciidoc index 3fdd9889e2..6ec25f470e 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-management-console-brute-force-of-root-user-identity.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-management-console-brute-force-of-root-user-identity.asciidoc @@ -49,6 +49,14 @@ Identifies a high number of failed authentication attempts to the AWS management ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/aws-management-console-root-login.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-management-console-root-login.asciidoc index 6f0010ac85..520935da9f 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-management-console-root-login.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-management-console-root-login.asciidoc @@ -51,7 +51,7 @@ Identifies a successful login to the AWS Management Console by the Root user. ### Investigating AWS Management Console Root Login -The AWS root account is the one identity that has complete access to all AWS services and resources in the account, which is created when the AWS account is created. AWS strongly recommends that you do not use the root user for your everyday tasks, even the administrative ones. Instead, adhere to the best practice of using the root user only to create your first IAM user. Then securely lock away the root user credentials and use them to perform only a few account and service management tasks. AWS provides a [list of the tasks that require root user](https://docs.aws.amazon.com/general/latest/gr/root-vs-iam.html#aws_tasks-that-require-root). +The AWS root account is the one identity that has complete access to all AWS services and resources in the account, which is created when the AWS account is created. AWS strongly recommends that you do not use the root user for your everyday tasks, even the administrative ones. Instead, adhere to the best practice of using the root user only to create your first IAM user. Then securely lock away the root user credentials and use them to perform only a few account and service management tasks. AWS provides a https://docs.aws.amazon.com/general/latest/gr/root-vs-iam.html#aws_tasks-that-require-root. This rule looks for attempts to log in to the AWS Management Console as the root user. @@ -79,10 +79,18 @@ services, and data accessed by the account in the last 24 hours. - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. - Identify if there are any regulatory or legal ramifications related to this activity. - Configure multi-factor authentication for the user. -- Follow security best practices [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS. +- Follow security best practices https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/ by AWS. - 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 + + +[source, markdown] +---------------------------------- +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/aws-rds-cluster-creation.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-rds-cluster-creation.asciidoc index e5429685a2..abb6833053 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-rds-cluster-creation.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-rds-cluster-creation.asciidoc @@ -52,6 +52,14 @@ Identifies the creation of a new Amazon Relational Database Service (RDS) Aurora ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/aws-rds-instance-cluster-stoppage.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-rds-instance-cluster-stoppage.asciidoc index 021a3d5159..0d6cfcaeba 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-rds-instance-cluster-stoppage.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-rds-instance-cluster-stoppage.asciidoc @@ -52,6 +52,14 @@ Identifies that an Amazon Relational Database Service (RDS) cluster or instance ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/aws-rds-instance-creation.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-rds-instance-creation.asciidoc index 73759b3ba2..ce6d7678d6 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-rds-instance-creation.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-rds-instance-creation.asciidoc @@ -50,6 +50,14 @@ Identifies the creation of an Amazon Relational Database Service (RDS) Aurora da ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/aws-rds-security-group-creation.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-rds-security-group-creation.asciidoc index 2d661d926c..26ec436143 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-rds-security-group-creation.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-rds-security-group-creation.asciidoc @@ -49,6 +49,14 @@ Identifies the creation of an Amazon Relational Database Service (RDS) Security ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/aws-rds-security-group-deletion.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-rds-security-group-deletion.asciidoc index fb99882493..50ea736798 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-rds-security-group-deletion.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-rds-security-group-deletion.asciidoc @@ -49,6 +49,14 @@ Identifies the deletion of an Amazon Relational Database Service (RDS) Security ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/aws-rds-snapshot-export.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-rds-snapshot-export.asciidoc index 5e7d339bab..1d95d577ff 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-rds-snapshot-export.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-rds-snapshot-export.asciidoc @@ -50,6 +50,14 @@ Identifies the export of an Amazon Relational Database Service (RDS) Aurora data ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/aws-rds-snapshot-restored.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-rds-snapshot-restored.asciidoc index bcdbc4d9a5..58c7a54272 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-rds-snapshot-restored.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-rds-snapshot-restored.asciidoc @@ -50,6 +50,14 @@ Identifies when an attempt was made to restore an RDS Snapshot. Snapshots are so ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/aws-redshift-cluster-creation.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-redshift-cluster-creation.asciidoc index 4a0264c25c..b5d0c75dac 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-redshift-cluster-creation.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-redshift-cluster-creation.asciidoc @@ -49,6 +49,14 @@ Identifies the creation of an Amazon Redshift cluster. Unexpected creation of th ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/aws-root-login-without-mfa.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-root-login-without-mfa.asciidoc index 94620b3416..01269426d0 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-root-login-without-mfa.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-root-login-without-mfa.asciidoc @@ -53,9 +53,9 @@ Identifies attempts to login to AWS as the root user without using multi-factor Multi-factor authentication (MFA) in AWS is a simple best practice that adds an extra layer of protection on top of your user name and password. With MFA enabled, when a user signs in to an AWS Management Console, they will be prompted for their user name and password, as well as for an authentication code from their AWS MFA device. Taken together, these multiple factors provide increased security for your AWS account settings and resources. -For more information about using MFA in AWS, access the [official documentation](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html). +For more information about using MFA in AWS, access the https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html. -The AWS root account is the one identity that has complete access to all AWS services and resources in the account, which is created when the AWS account is created. AWS strongly recommends that you do not use the root user for your everyday tasks, even the administrative ones. Instead, adhere to the best practice of using the root user only to create your first IAM user. Then securely lock away the root user credentials and use them to perform only a few account and service management tasks. Amazon provides a [list of the tasks that require root user](https://docs.aws.amazon.com/general/latest/gr/root-vs-iam.html#aws_tasks-that-require-root). +The AWS root account is the one identity that has complete access to all AWS services and resources in the account, which is created when the AWS account is created. AWS strongly recommends that you do not use the root user for your everyday tasks, even the administrative ones. Instead, adhere to the best practice of using the root user only to create your first IAM user. Then securely lock away the root user credentials and use them to perform only a few account and service management tasks. Amazon provides a https://docs.aws.amazon.com/general/latest/gr/root-vs-iam.html#aws_tasks-that-require-root. This rule looks for attempts to log in to AWS as the root user without using multi-factor authentication (MFA), meaning the account is not secured properly. @@ -83,10 +83,18 @@ services, and data accessed by the account in the last 24 hours. - Identify if the attacker is moving laterally and compromising other accounts, servers, or services. - Identify if there are any regulatory or legal ramifications related to this activity. - Configure multi-factor authentication for the user. -- Follow security best practices [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS. +- Follow security best practices https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/ by AWS. - 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 + + +[source, markdown] +---------------------------------- +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/aws-route-53-domain-transfer-lock-disabled.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-route-53-domain-transfer-lock-disabled.asciidoc index fe87560f89..e3c089f5ee 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-route-53-domain-transfer-lock-disabled.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-route-53-domain-transfer-lock-disabled.asciidoc @@ -51,6 +51,14 @@ Identifies when a transfer lock was removed from a Route 53 domain. It is recomm ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/aws-route-53-domain-transferred-to-another-account.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-route-53-domain-transferred-to-another-account.asciidoc index 751ab4cdff..f392326cbd 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-route-53-domain-transferred-to-another-account.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-route-53-domain-transferred-to-another-account.asciidoc @@ -50,6 +50,14 @@ Identifies when a request has been made to transfer a Route 53 domain to another ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/aws-route-table-created.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-route-table-created.asciidoc index aba024afba..5268c1aa0d 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-route-table-created.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-route-table-created.asciidoc @@ -52,6 +52,14 @@ Identifies when an AWS Route Table has been created. ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/aws-route-table-modified-or-deleted.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-route-table-modified-or-deleted.asciidoc index 3d20fc1c68..f5c396fc76 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-route-table-modified-or-deleted.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-route-table-modified-or-deleted.asciidoc @@ -56,6 +56,14 @@ Identifies when an AWS Route Table has been modified or deleted. ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/aws-route53-private-hosted-zone-associated-with-a-vpc.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-route53-private-hosted-zone-associated-with-a-vpc.asciidoc index 3a9b8bbdd2..8d68b82634 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-route53-private-hosted-zone-associated-with-a-vpc.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-route53-private-hosted-zone-associated-with-a-vpc.asciidoc @@ -49,6 +49,14 @@ Identifies when a Route53 private hosted zone has been associated with VPC. ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/aws-s3-bucket-configuration-deletion.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-s3-bucket-configuration-deletion.asciidoc index b84acc6666..1a0716e88d 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-s3-bucket-configuration-deletion.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-s3-bucket-configuration-deletion.asciidoc @@ -53,6 +53,14 @@ Identifies the deletion of various Amazon Simple Storage Service (S3) bucket con ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/aws-saml-activity.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-saml-activity.asciidoc index 99a1c887fd..a0633a01e0 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-saml-activity.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-saml-activity.asciidoc @@ -50,6 +50,14 @@ Identifies when SAML activity has occurred in AWS. An adversary could manipulate ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/aws-security-group-configuration-change-detection.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-security-group-configuration-change-detection.asciidoc index d357739fca..4e443b5d4f 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-security-group-configuration-change-detection.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-security-group-configuration-change-detection.asciidoc @@ -50,6 +50,14 @@ Identifies a change to an AWS Security Group Configuration. A security group is ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query 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 cfad4bcd1d..30cdb0f921 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 @@ -49,6 +49,14 @@ Identifies the use of AssumeRole. AssumeRole returns a set of temporary security ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/aws-sts-getsessiontoken-abuse.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-sts-getsessiontoken-abuse.asciidoc index 13932b6d0c..087c1a12e7 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-sts-getsessiontoken-abuse.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-sts-getsessiontoken-abuse.asciidoc @@ -49,6 +49,14 @@ Identifies the suspicious use of GetSessionToken. Tokens could be created and us ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/aws-vpc-flow-logs-deletion.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-vpc-flow-logs-deletion.asciidoc index eee7ed7680..06f018acec 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-vpc-flow-logs-deletion.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-vpc-flow-logs-deletion.asciidoc @@ -87,12 +87,20 @@ This rule identifies the deletion of VPC flow logs using the API `DeleteFlowLogs - 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 [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS. +- Implement security best practices https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/ 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 + + +[source, markdown] +---------------------------------- +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/aws-waf-access-control-list-deletion.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-waf-access-control-list-deletion.asciidoc index fa1b60867c..1d89a0723a 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-waf-access-control-list-deletion.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-waf-access-control-list-deletion.asciidoc @@ -50,6 +50,14 @@ Identifies the deletion of a specified AWS Web Application Firewall (WAF) access ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/aws-waf-rule-or-rule-group-deletion.asciidoc b/docs/detections/prebuilt-rules/rule-details/aws-waf-rule-or-rule-group-deletion.asciidoc index d780f96e5e..c175ba4474 100644 --- a/docs/detections/prebuilt-rules/rule-details/aws-waf-rule-or-rule-group-deletion.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/aws-waf-rule-or-rule-group-deletion.asciidoc @@ -50,6 +50,14 @@ Identifies the deletion of a specified AWS Web Application Firewall (WAF) rule o ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/azure-active-directory-high-risk-sign-in.asciidoc b/docs/detections/prebuilt-rules/rule-details/azure-active-directory-high-risk-sign-in.asciidoc index 52bbdfe300..8b2bb71107 100644 --- a/docs/detections/prebuilt-rules/rule-details/azure-active-directory-high-risk-sign-in.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/azure-active-directory-high-risk-sign-in.asciidoc @@ -59,7 +59,7 @@ This rule identifies events produced by Microsoft Identity Protection with high #### Possible investigation steps -- Identify the Risk Detection that triggered the event. A list with descriptions can be found [here](https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/concept-identity-protection-risks#risk-types-and-detection). +- Identify the Risk Detection that triggered the event. A list with descriptions can be found https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/concept-identity-protection-risks#risk-types-and-detection. - Identify the user account involved and validate whether the suspicious activity is normal for that user. - Consider the source IP address and geolocation for the involved user account. Do they look normal? - Consider the device used to sign in. Is it registered and compliant? @@ -85,11 +85,22 @@ If this rule is noisy in your environment due to expected activity, consider add - 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. -- Follow security best practices [outlined](https://docs.microsoft.com/en-us/azure/security/fundamentals/identity-management-best-practices) by Microsoft. +- Follow security best practices https://docs.microsoft.com/en-us/azure/security/fundamentals/identity-management-best-practices by Microsoft. - Determine 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 + + +[source, markdown] +---------------------------------- +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +Note that details for `azure.signinlogs.properties.risk_level_during_signin` and `azure.signinlogs.properties.risk_level_aggregated` +are only available for Azure AD Premium P2 customers. All other customers will be returned `hidden`. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/azure-active-directory-high-risk-user-sign-in-heuristic.asciidoc b/docs/detections/prebuilt-rules/rule-details/azure-active-directory-high-risk-user-sign-in-heuristic.asciidoc index bbc7978c2b..7d79b10970 100644 --- a/docs/detections/prebuilt-rules/rule-details/azure-active-directory-high-risk-user-sign-in-heuristic.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/azure-active-directory-high-risk-user-sign-in-heuristic.asciidoc @@ -59,7 +59,7 @@ This rule identifies events produced by the Microsoft Identity Protection with a #### Possible investigation steps -- Identify the Risk Detection that triggered the event. A list with descriptions can be found [here](https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/concept-identity-protection-risks#risk-types-and-detection). +- Identify the Risk Detection that triggered the event. A list with descriptions can be found https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/concept-identity-protection-risks#risk-types-and-detection. - Identify the user account involved and validate whether the suspicious activity is normal for that user. - Consider the source IP address and geolocation for the involved user account. Do they look normal? - Consider the device used to sign in. Is it registered and compliant? @@ -85,11 +85,19 @@ If this rule is noisy in your environment due to expected activity, consider add - 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. -- Follow security best practices [outlined](https://docs.microsoft.com/en-us/azure/security/fundamentals/identity-management-best-practices) by Microsoft. +- Follow security best practices https://docs.microsoft.com/en-us/azure/security/fundamentals/identity-management-best-practices by Microsoft. - Determine 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 + + +[source, markdown] +---------------------------------- +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/azure-active-directory-powershell-sign-in.asciidoc b/docs/detections/prebuilt-rules/rule-details/azure-active-directory-powershell-sign-in.asciidoc index 2f4d67829a..64df7d9713 100644 --- a/docs/detections/prebuilt-rules/rule-details/azure-active-directory-powershell-sign-in.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/azure-active-directory-powershell-sign-in.asciidoc @@ -82,11 +82,19 @@ This rule identifies sign-ins that use the Azure Active Directory PowerShell mod - 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. -- Follow security best practices [outlined](https://docs.microsoft.com/en-us/azure/security/fundamentals/identity-management-best-practices) by Microsoft. +- Follow security best practices https://docs.microsoft.com/en-us/azure/security/fundamentals/identity-management-best-practices by Microsoft. - Determine 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 + + +[source, markdown] +---------------------------------- +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/azure-ad-global-administrator-role-assigned.asciidoc b/docs/detections/prebuilt-rules/rule-details/azure-ad-global-administrator-role-assigned.asciidoc index 481a3798c7..7426b03eda 100644 --- a/docs/detections/prebuilt-rules/rule-details/azure-ad-global-administrator-role-assigned.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/azure-ad-global-administrator-role-assigned.asciidoc @@ -48,6 +48,14 @@ In Azure Active Directory (Azure AD), permissions to manage resources are assign ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/azure-alert-suppression-rule-created-or-modified.asciidoc b/docs/detections/prebuilt-rules/rule-details/azure-alert-suppression-rule-created-or-modified.asciidoc index 7c4a8a7936..dd542caa47 100644 --- a/docs/detections/prebuilt-rules/rule-details/azure-alert-suppression-rule-created-or-modified.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/azure-alert-suppression-rule-created-or-modified.asciidoc @@ -49,6 +49,14 @@ Identifies the creation of suppression rules in Azure. Suppression rules are a m ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/azure-application-credential-modification.asciidoc b/docs/detections/prebuilt-rules/rule-details/azure-application-credential-modification.asciidoc index b20e83c829..5094aaa616 100644 --- a/docs/detections/prebuilt-rules/rule-details/azure-application-credential-modification.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/azure-application-credential-modification.asciidoc @@ -48,6 +48,14 @@ Identifies when a new credential is added to an application in Azure. An applica ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/azure-automation-account-created.asciidoc b/docs/detections/prebuilt-rules/rule-details/azure-automation-account-created.asciidoc index 5576427780..a6b6b94286 100644 --- a/docs/detections/prebuilt-rules/rule-details/azure-automation-account-created.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/azure-automation-account-created.asciidoc @@ -51,6 +51,14 @@ Identifies when an Azure Automation account is created. Azure Automation account ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/azure-automation-runbook-created-or-modified.asciidoc b/docs/detections/prebuilt-rules/rule-details/azure-automation-runbook-created-or-modified.asciidoc index 5ceb539cb2..2d8f3e555e 100644 --- a/docs/detections/prebuilt-rules/rule-details/azure-automation-runbook-created-or-modified.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/azure-automation-runbook-created-or-modified.asciidoc @@ -51,6 +51,14 @@ Identifies when an Azure Automation runbook is created or modified. An adversary ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/azure-automation-runbook-deleted.asciidoc b/docs/detections/prebuilt-rules/rule-details/azure-automation-runbook-deleted.asciidoc index 309833f4fd..1b9b97ca17 100644 --- a/docs/detections/prebuilt-rules/rule-details/azure-automation-runbook-deleted.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/azure-automation-runbook-deleted.asciidoc @@ -51,6 +51,14 @@ Identifies when an Azure Automation runbook is deleted. An adversary may delete ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/azure-automation-webhook-created.asciidoc b/docs/detections/prebuilt-rules/rule-details/azure-automation-webhook-created.asciidoc index 5d76b6e861..a044ad1d6e 100644 --- a/docs/detections/prebuilt-rules/rule-details/azure-automation-webhook-created.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/azure-automation-webhook-created.asciidoc @@ -51,6 +51,14 @@ Identifies when an Azure Automation webhook is created. Azure Automation runbook ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/azure-blob-container-access-level-modification.asciidoc b/docs/detections/prebuilt-rules/rule-details/azure-blob-container-access-level-modification.asciidoc index f2b2a2dcb2..aaabe3a67c 100644 --- a/docs/detections/prebuilt-rules/rule-details/azure-blob-container-access-level-modification.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/azure-blob-container-access-level-modification.asciidoc @@ -48,6 +48,14 @@ Identifies changes to container access levels in Azure. Anonymous public read ac ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/azure-blob-permissions-modification.asciidoc b/docs/detections/prebuilt-rules/rule-details/azure-blob-permissions-modification.asciidoc index 3e7d67a10d..ab41afc7f9 100644 --- a/docs/detections/prebuilt-rules/rule-details/azure-blob-permissions-modification.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/azure-blob-permissions-modification.asciidoc @@ -49,6 +49,14 @@ Identifies when the Azure role-based access control (Azure RBAC) permissions are ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/azure-command-execution-on-virtual-machine.asciidoc b/docs/detections/prebuilt-rules/rule-details/azure-command-execution-on-virtual-machine.asciidoc index 571caaa1e5..de3b1bd8ff 100644 --- a/docs/detections/prebuilt-rules/rule-details/azure-command-execution-on-virtual-machine.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/azure-command-execution-on-virtual-machine.asciidoc @@ -50,6 +50,14 @@ Identifies command execution on a virtual machine (VM) in Azure. A Virtual Machi ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/azure-conditional-access-policy-modified.asciidoc b/docs/detections/prebuilt-rules/rule-details/azure-conditional-access-policy-modified.asciidoc index 708bdff0e8..9ba29d4e51 100644 --- a/docs/detections/prebuilt-rules/rule-details/azure-conditional-access-policy-modified.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/azure-conditional-access-policy-modified.asciidoc @@ -48,6 +48,14 @@ Identifies when an Azure Conditional Access policy is modified. Azure Conditiona ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/azure-diagnostic-settings-deletion.asciidoc b/docs/detections/prebuilt-rules/rule-details/azure-diagnostic-settings-deletion.asciidoc index 2ba4ca859e..ccb9a03d88 100644 --- a/docs/detections/prebuilt-rules/rule-details/azure-diagnostic-settings-deletion.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/azure-diagnostic-settings-deletion.asciidoc @@ -47,6 +47,14 @@ Identifies the deletion of diagnostic settings in Azure, which send platform log ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/azure-event-hub-authorization-rule-created-or-updated.asciidoc b/docs/detections/prebuilt-rules/rule-details/azure-event-hub-authorization-rule-created-or-updated.asciidoc index 426015a78d..d1c0bc83cc 100644 --- a/docs/detections/prebuilt-rules/rule-details/azure-event-hub-authorization-rule-created-or-updated.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/azure-event-hub-authorization-rule-created-or-updated.asciidoc @@ -48,6 +48,14 @@ Identifies when an Event Hub Authorization Rule is created or updated in Azure. ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/azure-event-hub-deletion.asciidoc b/docs/detections/prebuilt-rules/rule-details/azure-event-hub-deletion.asciidoc index d14060328b..75a3e4c90f 100644 --- a/docs/detections/prebuilt-rules/rule-details/azure-event-hub-deletion.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/azure-event-hub-deletion.asciidoc @@ -50,6 +50,14 @@ Identifies an Event Hub deletion in Azure. An Event Hub is an event processing s ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/azure-external-guest-user-invitation.asciidoc b/docs/detections/prebuilt-rules/rule-details/azure-external-guest-user-invitation.asciidoc index c84bb7b894..88bc1ab96f 100644 --- a/docs/detections/prebuilt-rules/rule-details/azure-external-guest-user-invitation.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/azure-external-guest-user-invitation.asciidoc @@ -48,6 +48,14 @@ Identifies an invitation to an external user in Azure Active Directory (AD). Azu ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/azure-firewall-policy-deletion.asciidoc b/docs/detections/prebuilt-rules/rule-details/azure-firewall-policy-deletion.asciidoc index 114e2b6a33..3de07273b4 100644 --- a/docs/detections/prebuilt-rules/rule-details/azure-firewall-policy-deletion.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/azure-firewall-policy-deletion.asciidoc @@ -48,6 +48,14 @@ Identifies the deletion of a firewall policy in Azure. An adversary may delete a ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/azure-frontdoor-web-application-firewall-waf-policy-deleted.asciidoc b/docs/detections/prebuilt-rules/rule-details/azure-frontdoor-web-application-firewall-waf-policy-deleted.asciidoc index 315d0a2c8c..f9d59bf286 100644 --- a/docs/detections/prebuilt-rules/rule-details/azure-frontdoor-web-application-firewall-waf-policy-deleted.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/azure-frontdoor-web-application-firewall-waf-policy-deleted.asciidoc @@ -48,6 +48,14 @@ Identifies the deletion of a Frontdoor Web Application Firewall (WAF) Policy in ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/azure-full-network-packet-capture-detected.asciidoc b/docs/detections/prebuilt-rules/rule-details/azure-full-network-packet-capture-detected.asciidoc index f0350e0323..b1d432d043 100644 --- a/docs/detections/prebuilt-rules/rule-details/azure-full-network-packet-capture-detected.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/azure-full-network-packet-capture-detected.asciidoc @@ -47,6 +47,14 @@ Identifies potential full network packet capture in Azure. Packet Capture is an ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/azure-global-administrator-role-addition-to-pim-user.asciidoc b/docs/detections/prebuilt-rules/rule-details/azure-global-administrator-role-addition-to-pim-user.asciidoc index 5343ac7f7b..9bd5847bdb 100644 --- a/docs/detections/prebuilt-rules/rule-details/azure-global-administrator-role-addition-to-pim-user.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/azure-global-administrator-role-addition-to-pim-user.asciidoc @@ -48,6 +48,14 @@ Identifies an Azure Active Directory (AD) Global Administrator role addition to ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/azure-key-vault-modified.asciidoc b/docs/detections/prebuilt-rules/rule-details/azure-key-vault-modified.asciidoc index 3cf20294f6..3529ba1684 100644 --- a/docs/detections/prebuilt-rules/rule-details/azure-key-vault-modified.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/azure-key-vault-modified.asciidoc @@ -49,6 +49,14 @@ Identifies modifications to a Key Vault in Azure. The Key Vault is a service tha ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/azure-kubernetes-events-deleted.asciidoc b/docs/detections/prebuilt-rules/rule-details/azure-kubernetes-events-deleted.asciidoc index 803416351d..04a9dd165c 100644 --- a/docs/detections/prebuilt-rules/rule-details/azure-kubernetes-events-deleted.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/azure-kubernetes-events-deleted.asciidoc @@ -48,6 +48,14 @@ Identifies when events are deleted in Azure Kubernetes. Kubernetes events are ob ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/azure-kubernetes-pods-deleted.asciidoc b/docs/detections/prebuilt-rules/rule-details/azure-kubernetes-pods-deleted.asciidoc index 62e26f3bfe..6580217556 100644 --- a/docs/detections/prebuilt-rules/rule-details/azure-kubernetes-pods-deleted.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/azure-kubernetes-pods-deleted.asciidoc @@ -48,6 +48,14 @@ Identifies the deletion of Azure Kubernetes Pods. Adversaries may delete a Kuber ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/azure-kubernetes-rolebindings-created.asciidoc b/docs/detections/prebuilt-rules/rule-details/azure-kubernetes-rolebindings-created.asciidoc index 50d87dfe47..869ee3d948 100644 --- a/docs/detections/prebuilt-rules/rule-details/azure-kubernetes-rolebindings-created.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/azure-kubernetes-rolebindings-created.asciidoc @@ -49,6 +49,14 @@ Identifies the creation of role binding or cluster role bindings. You can assign ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/azure-network-watcher-deletion.asciidoc b/docs/detections/prebuilt-rules/rule-details/azure-network-watcher-deletion.asciidoc index d94f3640f8..a82039d60f 100644 --- a/docs/detections/prebuilt-rules/rule-details/azure-network-watcher-deletion.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/azure-network-watcher-deletion.asciidoc @@ -48,6 +48,14 @@ Identifies the deletion of a Network Watcher in Azure. Network Watchers are used ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/azure-privilege-identity-management-role-modified.asciidoc b/docs/detections/prebuilt-rules/rule-details/azure-privilege-identity-management-role-modified.asciidoc index 2b76402507..51fd59c05d 100644 --- a/docs/detections/prebuilt-rules/rule-details/azure-privilege-identity-management-role-modified.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/azure-privilege-identity-management-role-modified.asciidoc @@ -84,11 +84,19 @@ This rule identifies the update of PIM role settings, which can indicate that an - Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users. - Restore the PIM roles to the desired state. - Consider enabling multi-factor authentication for users. -- Follow security best practices [outlined](https://docs.microsoft.com/en-us/azure/security/fundamentals/identity-management-best-practices) by Microsoft. +- Follow security best practices https://docs.microsoft.com/en-us/azure/security/fundamentals/identity-management-best-practices by Microsoft. - Determine 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 + + +[source, markdown] +---------------------------------- +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/azure-resource-group-deletion.asciidoc b/docs/detections/prebuilt-rules/rule-details/azure-resource-group-deletion.asciidoc index 5dcd685891..8553590f22 100644 --- a/docs/detections/prebuilt-rules/rule-details/azure-resource-group-deletion.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/azure-resource-group-deletion.asciidoc @@ -48,6 +48,14 @@ Identifies the deletion of a resource group in Azure, which includes all resourc ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/azure-service-principal-addition.asciidoc b/docs/detections/prebuilt-rules/rule-details/azure-service-principal-addition.asciidoc index be292479fb..8dba242568 100644 --- a/docs/detections/prebuilt-rules/rule-details/azure-service-principal-addition.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/azure-service-principal-addition.asciidoc @@ -83,11 +83,19 @@ If this rule is noisy in your environment due to expected activity, consider add - 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. -- Follow security best practices [outlined](https://docs.microsoft.com/en-us/azure/security/fundamentals/identity-management-best-practices) by Microsoft. +- Follow security best practices https://docs.microsoft.com/en-us/azure/security/fundamentals/identity-management-best-practices by Microsoft. - Determine 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 + + +[source, markdown] +---------------------------------- +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/azure-service-principal-credentials-added.asciidoc b/docs/detections/prebuilt-rules/rule-details/azure-service-principal-credentials-added.asciidoc index 42459bb422..8e7515d179 100644 --- a/docs/detections/prebuilt-rules/rule-details/azure-service-principal-credentials-added.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/azure-service-principal-credentials-added.asciidoc @@ -49,6 +49,14 @@ Identifies when new Service Principal credentials have been added in Azure. In m ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/azure-storage-account-key-regenerated.asciidoc b/docs/detections/prebuilt-rules/rule-details/azure-storage-account-key-regenerated.asciidoc index 04e8f8637f..4adc5dac1e 100644 --- a/docs/detections/prebuilt-rules/rule-details/azure-storage-account-key-regenerated.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/azure-storage-account-key-regenerated.asciidoc @@ -48,6 +48,14 @@ Identifies a rotation to storage account access keys in Azure. Regenerating acce ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/azure-virtual-network-device-modified-or-deleted.asciidoc b/docs/detections/prebuilt-rules/rule-details/azure-virtual-network-device-modified-or-deleted.asciidoc index d7cbdd5d9b..1542f85df9 100644 --- a/docs/detections/prebuilt-rules/rule-details/azure-virtual-network-device-modified-or-deleted.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/azure-virtual-network-device-modified-or-deleted.asciidoc @@ -48,6 +48,14 @@ Identifies when a virtual network device is modified or deleted. This can be a n ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/base16-or-base32-encoding-decoding-activity.asciidoc b/docs/detections/prebuilt-rules/rule-details/base16-or-base32-encoding-decoding-activity.asciidoc index a0d3d1e857..0a0643ced3 100644 --- a/docs/detections/prebuilt-rules/rule-details/base16-or-base32-encoding-decoding-activity.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/base16-or-base32-encoding-decoding-activity.asciidoc @@ -41,6 +41,50 @@ Adversaries may encode/decode data in an attempt to evade detection by host- or *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Auditbeat + +### 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. + +#### 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. +- 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. +- 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. + +### Auditbeat Setup +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + +#### The following steps should be executed in order to add the Auditbeat on a Linux System: +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/binary-executed-from-shared-memory-directory.asciidoc b/docs/detections/prebuilt-rules/rule-details/binary-executed-from-shared-memory-directory.asciidoc index 42b10a0d11..a41152816e 100644 --- a/docs/detections/prebuilt-rules/rule-details/binary-executed-from-shared-memory-directory.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/binary-executed-from-shared-memory-directory.asciidoc @@ -45,6 +45,38 @@ Identifies the execution of a binary by root in Linux shared memory directories: *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/bpf-filter-applied-using-tc.asciidoc b/docs/detections/prebuilt-rules/rule-details/bpf-filter-applied-using-tc.asciidoc index 4fabe76455..cf51ddbba5 100644 --- a/docs/detections/prebuilt-rules/rule-details/bpf-filter-applied-using-tc.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/bpf-filter-applied-using-tc.asciidoc @@ -44,6 +44,38 @@ Detects when the tc (transmission control) binary is utilized to set a BPF (Berk *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/bypass-uac-via-event-viewer.asciidoc b/docs/detections/prebuilt-rules/rule-details/bypass-uac-via-event-viewer.asciidoc index a192627abb..b01a95801e 100644 --- a/docs/detections/prebuilt-rules/rule-details/bypass-uac-via-event-viewer.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/bypass-uac-via-event-viewer.asciidoc @@ -56,12 +56,12 @@ Identifies User Account Control (UAC) bypass via eventvwr.exe. Attackers bypass Windows User Account Control (UAC) allows a program to elevate its privileges (tracked as low to high integrity levels) to perform a task under administrator-level permissions, possibly by prompting the user for confirmation. UAC can deny an operation under high-integrity enforcement, or allow the user to perform the action if they are in the local administrators group and enter an administrator password when prompted. -For more information about the UAC and how it works, check the [official Microsoft docs page](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/how-user-account-control-works). +For more information about the UAC and how it works, check the https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/how-user-account-control-works. During startup, `eventvwr.exe` checks the registry value of the `HKCU\Software\Classes\mscfile\shell\open\command` registry key for the location of `mmc.exe`, which is used to open the `eventvwr.msc` saved console file. If the location of another binary or script is added to this registry value, it will be executed as a high-integrity process without a UAC prompt being displayed to the user. This rule detects this UAC bypass by monitoring processes spawned by `eventvwr.exe` other than `mmc.exe` and `werfault.exe`. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps @@ -105,6 +105,20 @@ During startup, `eventvwr.exe` checks the registry value of the `HKCU\Software\C - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/cap-sys-admin-assigned-to-binary.asciidoc b/docs/detections/prebuilt-rules/rule-details/cap-sys-admin-assigned-to-binary.asciidoc index fda72bbedd..2f687597e7 100644 --- a/docs/detections/prebuilt-rules/rule-details/cap-sys-admin-assigned-to-binary.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/cap-sys-admin-assigned-to-binary.asciidoc @@ -39,6 +39,38 @@ Identifies instances where a binary is granted the CAP_SYS_ADMIN capability. In *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/chkconfig-service-add.asciidoc b/docs/detections/prebuilt-rules/rule-details/chkconfig-service-add.asciidoc index e8032a3170..eab8e4689b 100644 --- a/docs/detections/prebuilt-rules/rule-details/chkconfig-service-add.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/chkconfig-service-add.asciidoc @@ -58,8 +58,8 @@ Malicious actors can leverage services to achieve persistence by creating or mod This rule monitors the usage of the `chkconfig` binary to manually add a service for management by `chkconfig`, potentially indicating the creation of a persistence mechanism. > **Note**: -> This investigation guide uses the {security-guide}/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. -> This investigation guide uses {security-guide}/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. #### Possible Investigation Steps @@ -123,6 +123,38 @@ This rule monitors the usage of the `chkconfig` binary to manually add a service - Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. - Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). +---------------------------------- + +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/clearing-windows-console-history.asciidoc b/docs/detections/prebuilt-rules/rule-details/clearing-windows-console-history.asciidoc index 08f847f364..eab2164684 100644 --- a/docs/detections/prebuilt-rules/rule-details/clearing-windows-console-history.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/clearing-windows-console-history.asciidoc @@ -86,6 +86,20 @@ Attackers can try to cover their tracks by clearing PowerShell console history. - Ensure that PowerShell auditing policies and log collection are in place to grant future visibility. +---------------------------------- + +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/clearing-windows-event-logs.asciidoc b/docs/detections/prebuilt-rules/rule-details/clearing-windows-event-logs.asciidoc index 4eda719eba..f5078cfc17 100644 --- a/docs/detections/prebuilt-rules/rule-details/clearing-windows-event-logs.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/clearing-windows-event-logs.asciidoc @@ -82,6 +82,20 @@ This rule looks for the execution of the `wevtutil.exe` utility or the `Clear-Ev - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/code-signing-policy-modification-through-built-in-tools.asciidoc b/docs/detections/prebuilt-rules/rule-details/code-signing-policy-modification-through-built-in-tools.asciidoc index c03bd5fa1f..208dde2bb3 100644 --- a/docs/detections/prebuilt-rules/rule-details/code-signing-policy-modification-through-built-in-tools.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/code-signing-policy-modification-through-built-in-tools.asciidoc @@ -60,7 +60,7 @@ This protection is essential for maintaining the security of the system. However This rule identifies commands that can disable the Driver Signature Enforcement feature. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps diff --git a/docs/detections/prebuilt-rules/rule-details/code-signing-policy-modification-through-registry.asciidoc b/docs/detections/prebuilt-rules/rule-details/code-signing-policy-modification-through-registry.asciidoc index f85b9c4154..555da593f4 100644 --- a/docs/detections/prebuilt-rules/rule-details/code-signing-policy-modification-through-registry.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/code-signing-policy-modification-through-registry.asciidoc @@ -59,7 +59,7 @@ This protection is essential for maintaining system security. However, attackers This rule identifies registry modifications that can disable DSE. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps diff --git a/docs/detections/prebuilt-rules/rule-details/command-execution-via-solarwinds-process.asciidoc b/docs/detections/prebuilt-rules/rule-details/command-execution-via-solarwinds-process.asciidoc index a34e821cf5..c2a28202b8 100644 --- a/docs/detections/prebuilt-rules/rule-details/command-execution-via-solarwinds-process.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/command-execution-via-solarwinds-process.asciidoc @@ -47,6 +47,20 @@ A suspicious SolarWinds child process (Cmd.exe or Powershell.exe) was detected. *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/command-prompt-network-connection.asciidoc b/docs/detections/prebuilt-rules/rule-details/command-prompt-network-connection.asciidoc index 34694449ce..1056613202 100644 --- a/docs/detections/prebuilt-rules/rule-details/command-prompt-network-connection.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/command-prompt-network-connection.asciidoc @@ -57,7 +57,7 @@ Attackers commonly transfer tooling or malware from external systems into a comp This rule looks for a network connection to an external address from the `cmd.exe` utility, which can indicate the abuse of the utility to download malicious files and tools. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps diff --git a/docs/detections/prebuilt-rules/rule-details/command-shell-activity-started-via-rundll32.asciidoc b/docs/detections/prebuilt-rules/rule-details/command-shell-activity-started-via-rundll32.asciidoc index 22fd7634c5..7ccc29f6f9 100644 --- a/docs/detections/prebuilt-rules/rule-details/command-shell-activity-started-via-rundll32.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/command-shell-activity-started-via-rundll32.asciidoc @@ -44,6 +44,20 @@ Identifies command shell activity started via RunDLL32, which is commonly abused *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/component-object-model-hijacking.asciidoc b/docs/detections/prebuilt-rules/rule-details/component-object-model-hijacking.asciidoc index 21968e230a..8a62c4fb7a 100644 --- a/docs/detections/prebuilt-rules/rule-details/component-object-model-hijacking.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/component-object-model-hijacking.asciidoc @@ -92,6 +92,20 @@ Adversaries can insert malicious code that can be executed in place of legitimat +---------------------------------- + +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/conhost-spawned-by-suspicious-parent-process.asciidoc b/docs/detections/prebuilt-rules/rule-details/conhost-spawned-by-suspicious-parent-process.asciidoc index 3fedaa14ce..37cb59c477 100644 --- a/docs/detections/prebuilt-rules/rule-details/conhost-spawned-by-suspicious-parent-process.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/conhost-spawned-by-suspicious-parent-process.asciidoc @@ -101,6 +101,20 @@ Attackers often rely on custom shell implementations to avoid using built-in com - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/connection-to-commonly-abused-free-ssl-certificate-providers.asciidoc b/docs/detections/prebuilt-rules/rule-details/connection-to-commonly-abused-free-ssl-certificate-providers.asciidoc index 9caed9bfb2..d55a5d6bce 100644 --- a/docs/detections/prebuilt-rules/rule-details/connection-to-commonly-abused-free-ssl-certificate-providers.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/connection-to-commonly-abused-free-ssl-certificate-providers.asciidoc @@ -40,6 +40,20 @@ Identifies unusual processes connecting to domains using known free SSL certific *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/connection-to-commonly-abused-web-services.asciidoc b/docs/detections/prebuilt-rules/rule-details/connection-to-commonly-abused-web-services.asciidoc index d39903b20b..85965ae766 100644 --- a/docs/detections/prebuilt-rules/rule-details/connection-to-commonly-abused-web-services.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/connection-to-commonly-abused-web-services.asciidoc @@ -53,8 +53,8 @@ Adversaries may use an existing, legitimate external Web service as a means for This rule looks for processes outside known legitimate program locations communicating with a list of services that can be abused for exfiltration or command and control. > **Note**: -> This investigation guide uses the {security-guide}/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. -> This investigation guide uses the {security-guide}/security/master/interactive-investigation-guides.html[Investigate Markdown Plugin] introduced in Elastic Stack version 8.8.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/interactive-investigation-guides.html introduced in Elastic Stack version 8.8.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps diff --git a/docs/detections/prebuilt-rules/rule-details/connection-to-external-network-via-telnet.asciidoc b/docs/detections/prebuilt-rules/rule-details/connection-to-external-network-via-telnet.asciidoc index c1e6ec5185..d879df4ad0 100644 --- a/docs/detections/prebuilt-rules/rule-details/connection-to-external-network-via-telnet.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/connection-to-external-network-via-telnet.asciidoc @@ -41,6 +41,50 @@ Telnet provides a command line interface for communication with a remote device *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Auditbeat + +### 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. + +#### 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. +- 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. +- 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. + +### Auditbeat Setup +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + +#### The following steps should be executed in order to add the Auditbeat on a Linux System: +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/connection-to-internal-network-via-telnet.asciidoc b/docs/detections/prebuilt-rules/rule-details/connection-to-internal-network-via-telnet.asciidoc index 3a91d4f2fd..2c9315c8f6 100644 --- a/docs/detections/prebuilt-rules/rule-details/connection-to-internal-network-via-telnet.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/connection-to-internal-network-via-telnet.asciidoc @@ -41,6 +41,50 @@ Telnet provides a command line interface for communication with a remote device *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Auditbeat + +### 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. + +#### 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. +- 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. +- 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. + +### Auditbeat Setup +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + +#### The following steps should be executed in order to add the Auditbeat on a Linux System: +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/control-panel-process-with-unusual-arguments.asciidoc b/docs/detections/prebuilt-rules/rule-details/control-panel-process-with-unusual-arguments.asciidoc index 8bff7e56e1..642c96923c 100644 --- a/docs/detections/prebuilt-rules/rule-details/control-panel-process-with-unusual-arguments.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/control-panel-process-with-unusual-arguments.asciidoc @@ -46,6 +46,20 @@ Identifies unusual instances of Control Panel with suspicious keywords or paths *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/creation-of-a-hidden-local-user-account.asciidoc b/docs/detections/prebuilt-rules/rule-details/creation-of-a-hidden-local-user-account.asciidoc index 45ad1fca43..103e7f4ffa 100644 --- a/docs/detections/prebuilt-rules/rule-details/creation-of-a-hidden-local-user-account.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/creation-of-a-hidden-local-user-account.asciidoc @@ -79,6 +79,20 @@ This rule uses registry events to identify the creation of local hidden accounts - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/creation-of-hidden-files-and-directories-via-commandline.asciidoc b/docs/detections/prebuilt-rules/rule-details/creation-of-hidden-files-and-directories-via-commandline.asciidoc index b5ca363806..c7fe543322 100644 --- a/docs/detections/prebuilt-rules/rule-details/creation-of-hidden-files-and-directories-via-commandline.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/creation-of-hidden-files-and-directories-via-commandline.asciidoc @@ -39,6 +39,53 @@ Users can mark specific files as hidden simply by putting a "." as the first cha *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Auditbeat + +### 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. + +#### 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. +- 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. +- 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. + +### Auditbeat Setup +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + +#### The following steps should be executed in order to add the Auditbeat on a Linux System: +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html. + +#### Custom Ingest Pipeline +For versions <8.2, you need to add a custom ingest pipeline to populate `event.ingested` with @timestamp for non-elastic-agent indexes, like auditbeats/filebeat/winlogbeat etc. For more details to add a custom ingest pipeline refer to the https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/creation-of-hidden-launch-agent-or-daemon.asciidoc b/docs/detections/prebuilt-rules/rule-details/creation-of-hidden-launch-agent-or-daemon.asciidoc index 9667325f4d..4d0b3021f3 100644 --- a/docs/detections/prebuilt-rules/rule-details/creation-of-hidden-launch-agent-or-daemon.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/creation-of-hidden-launch-agent-or-daemon.asciidoc @@ -41,6 +41,38 @@ Identifies the creation of a hidden launch agent or daemon. An adversary may est *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### The following steps should be executed in order to add the Elastic Defend integration on a macOS 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, for MacOS it is recommended to select "Traditional Endpoints". +- 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/creation-of-hidden-login-item-via-apple-script.asciidoc b/docs/detections/prebuilt-rules/rule-details/creation-of-hidden-login-item-via-apple-script.asciidoc index dc052f78df..67442b5aa6 100644 --- a/docs/detections/prebuilt-rules/rule-details/creation-of-hidden-login-item-via-apple-script.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/creation-of-hidden-login-item-via-apple-script.asciidoc @@ -39,6 +39,38 @@ Identifies the execution of osascript to create a hidden login item. This may in *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### The following steps should be executed in order to add the Elastic Defend integration on a macOS 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, for MacOS it is recommended to select "Traditional Endpoints". +- 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/creation-of-hidden-shared-object-file.asciidoc b/docs/detections/prebuilt-rules/rule-details/creation-of-hidden-shared-object-file.asciidoc index 03b9f05085..a6a24c288e 100644 --- a/docs/detections/prebuilt-rules/rule-details/creation-of-hidden-shared-object-file.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/creation-of-hidden-shared-object-file.asciidoc @@ -41,6 +41,53 @@ Identifies the creation of a hidden shared object (.so) file. Users can mark spe *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Auditbeat + +### 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. + +#### 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. +- 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. +- 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. + +### Auditbeat Setup +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + +#### The following steps should be executed in order to add the Auditbeat on a Linux System: +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html. + +#### Custom Ingest Pipeline +For versions <8.2, you need to add a custom ingest pipeline to populate `event.ingested` with @timestamp for non-elastic-agent indexes, like auditbeats/filebeat/winlogbeat etc. For more details to add a custom ingest pipeline refer to the https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/creation-or-modification-of-a-new-gpo-scheduled-task-or-service.asciidoc b/docs/detections/prebuilt-rules/rule-details/creation-or-modification-of-a-new-gpo-scheduled-task-or-service.asciidoc index 57a8f62dc3..224530be48 100644 --- a/docs/detections/prebuilt-rules/rule-details/creation-or-modification-of-a-new-gpo-scheduled-task-or-service.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/creation-or-modification-of-a-new-gpo-scheduled-task-or-service.asciidoc @@ -43,6 +43,20 @@ Detects the creation or modification of a new Group Policy based scheduled task *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/creation-or-modification-of-domain-backup-dpapi-private-key.asciidoc b/docs/detections/prebuilt-rules/rule-details/creation-or-modification-of-domain-backup-dpapi-private-key.asciidoc index 39d078f720..1a6eb1f200 100644 --- a/docs/detections/prebuilt-rules/rule-details/creation-or-modification-of-domain-backup-dpapi-private-key.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/creation-or-modification-of-domain-backup-dpapi-private-key.asciidoc @@ -55,6 +55,20 @@ Identifies the creation or modification of Domain Backup private keys. Adversari Domain DPAPI Backup keys are stored on domain controllers and can be dumped remotely with tools such as Mimikatz. The resulting .pvk private key can be used to decrypt ANY domain user masterkeys, which then can be used to decrypt any secrets protected by those keys. +---------------------------------- + +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/creation-or-modification-of-root-certificate.asciidoc b/docs/detections/prebuilt-rules/rule-details/creation-or-modification-of-root-certificate.asciidoc index edcb7c30d5..f5a7983d18 100644 --- a/docs/detections/prebuilt-rules/rule-details/creation-or-modification-of-root-certificate.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/creation-or-modification-of-root-certificate.asciidoc @@ -57,7 +57,7 @@ Identifies the creation or modification of a local trusted root certificate in W Root certificates are the primary level of certifications that tell a browser that the communication is trusted and legitimate. This verification is based upon the identification of a certification authority. Windows adds several trusted root certificates so browsers can use them to communicate with websites. -[Check out this post](https://www.thewindowsclub.com/what-are-root-certificates-windows) for more details on root certificates and the involved cryptography. +https://www.thewindowsclub.com/what-are-root-certificates-windows for more details on root certificates and the involved cryptography. This rule identifies the creation or modification of a root certificate by monitoring registry modifications. The installation of a malicious root certificate would allow an attacker the ability to masquerade malicious files as valid signed components from any entity (for example, Microsoft). It could also allow an attacker to decrypt SSL traffic. @@ -97,6 +97,20 @@ This rule identifies the creation or modification of a root certificate by monit - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/credential-acquisition-via-registry-hive-dumping.asciidoc b/docs/detections/prebuilt-rules/rule-details/credential-acquisition-via-registry-hive-dumping.asciidoc index 57eff26c80..8b7310a21c 100644 --- a/docs/detections/prebuilt-rules/rule-details/credential-acquisition-via-registry-hive-dumping.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/credential-acquisition-via-registry-hive-dumping.asciidoc @@ -92,6 +92,20 @@ This rule identifies the usage of `reg.exe` to dump SECURITY and/or SAM hives, w - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/cron-job-created-or-changed-by-previously-unknown-process.asciidoc b/docs/detections/prebuilt-rules/rule-details/cron-job-created-or-changed-by-previously-unknown-process.asciidoc index 94c44f3ec5..e46cbd0eb5 100644 --- a/docs/detections/prebuilt-rules/rule-details/cron-job-created-or-changed-by-previously-unknown-process.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/cron-job-created-or-changed-by-previously-unknown-process.asciidoc @@ -59,8 +59,8 @@ By creating or modifying cron job configurations, attackers can execute maliciou This rule monitors the creation of previously unknown cron jobs by monitoring for file creation events in the most common cron job task location directories. > **Note**: -> This investigation guide uses the {security-guide}/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. -> This investigation guide uses {security-guide}/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. #### Possible Investigation Steps @@ -119,6 +119,38 @@ This rule monitors the creation of previously unknown cron jobs by monitoring fo - Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. - Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). +---------------------------------- + +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/cyberark-privileged-access-security-error.asciidoc b/docs/detections/prebuilt-rules/rule-details/cyberark-privileged-access-security-error.asciidoc index 3b5e3a23a9..9ee9e20b8e 100644 --- a/docs/detections/prebuilt-rules/rule-details/cyberark-privileged-access-security-error.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/cyberark-privileged-access-security-error.asciidoc @@ -51,6 +51,14 @@ This is a promotion rule for CyberArk error events, which are alertable events p Consult vendor documentation on interpreting specific events. ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The CyberArk Privileged Access Security (PAS) Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/cyberark-privileged-access-security-recommended-monitor.asciidoc b/docs/detections/prebuilt-rules/rule-details/cyberark-privileged-access-security-recommended-monitor.asciidoc index 77ab8d1406..8613634a83 100644 --- a/docs/detections/prebuilt-rules/rule-details/cyberark-privileged-access-security-recommended-monitor.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/cyberark-privileged-access-security-recommended-monitor.asciidoc @@ -51,6 +51,14 @@ This is a promotion rule for CyberArk events, which the vendor recommends should Consult vendor documentation on interpreting specific events. ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The CyberArk Privileged Access Security (PAS) Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/deleting-backup-catalogs-with-wbadmin.asciidoc b/docs/detections/prebuilt-rules/rule-details/deleting-backup-catalogs-with-wbadmin.asciidoc index 3a2b06c883..c721ce51b7 100644 --- a/docs/detections/prebuilt-rules/rule-details/deleting-backup-catalogs-with-wbadmin.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/deleting-backup-catalogs-with-wbadmin.asciidoc @@ -89,6 +89,20 @@ This rule identifies the deletion of the backup catalog using the `wbadmin.exe` - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/direct-outbound-smb-connection.asciidoc b/docs/detections/prebuilt-rules/rule-details/direct-outbound-smb-connection.asciidoc index 96f4750e33..dd38e9bbb8 100644 --- a/docs/detections/prebuilt-rules/rule-details/direct-outbound-smb-connection.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/direct-outbound-smb-connection.asciidoc @@ -51,7 +51,7 @@ Identifies unexpected processes making network connections over port 445. Window This rule looks for unexpected processes making network connections over port 445. Windows file sharing is typically implemented over Server Message Block (SMB), which communicates between hosts using port 445. When legitimate, these network connections are established by the kernel (PID 4). Occurrences of non-system processes using this port can indicate port scanners, exploits, and tools used to move laterally on the environment. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps diff --git a/docs/detections/prebuilt-rules/rule-details/disable-windows-event-and-security-logs-using-built-in-tools.asciidoc b/docs/detections/prebuilt-rules/rule-details/disable-windows-event-and-security-logs-using-built-in-tools.asciidoc index e445897d51..645ff42675 100644 --- a/docs/detections/prebuilt-rules/rule-details/disable-windows-event-and-security-logs-using-built-in-tools.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/disable-windows-event-and-security-logs-using-built-in-tools.asciidoc @@ -86,6 +86,20 @@ This rule looks for the usage of different utilities to disable the EventLog ser - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/disable-windows-firewall-rules-via-netsh.asciidoc b/docs/detections/prebuilt-rules/rule-details/disable-windows-firewall-rules-via-netsh.asciidoc index 567332f70c..4ab18c31ca 100644 --- a/docs/detections/prebuilt-rules/rule-details/disable-windows-firewall-rules-via-netsh.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/disable-windows-firewall-rules-via-netsh.asciidoc @@ -80,6 +80,20 @@ This rule identifies patterns related to disabling the Windows firewall or its r - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/disabling-user-account-control-via-registry-modification.asciidoc b/docs/detections/prebuilt-rules/rule-details/disabling-user-account-control-via-registry-modification.asciidoc index 45cc0ed2a5..9fc100822c 100644 --- a/docs/detections/prebuilt-rules/rule-details/disabling-user-account-control-via-registry-modification.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/disabling-user-account-control-via-registry-modification.asciidoc @@ -58,7 +58,7 @@ User Account Control (UAC) can help mitigate the impact of malware on Windows ho Windows User Account Control (UAC) allows a program to elevate its privileges (tracked as low to high integrity levels) to perform a task under administrator-level permissions, possibly by prompting the user for confirmation. UAC can deny an operation under high-integrity enforcement, or allow the user to perform the action if they are in the local administrators group and enter an administrator password when prompted. -For more information about the UAC and how it works, check the [official Microsoft docs page](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/how-user-account-control-works). +For more information about the UAC and how it works, check the https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/how-user-account-control-works. Attackers may disable UAC to execute code directly in high integrity. This rule identifies registry value changes to bypass the UAC protection. @@ -100,6 +100,20 @@ Attackers may disable UAC to execute code directly in high integrity. This rule - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/disabling-windows-defender-security-settings-via-powershell.asciidoc b/docs/detections/prebuilt-rules/rule-details/disabling-windows-defender-security-settings-via-powershell.asciidoc index 9a36907e25..899362c9a2 100644 --- a/docs/detections/prebuilt-rules/rule-details/disabling-windows-defender-security-settings-via-powershell.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/disabling-windows-defender-security-settings-via-powershell.asciidoc @@ -89,6 +89,20 @@ This rule monitors the execution of commands that can tamper the Windows Defende - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/dns-over-https-enabled-via-registry.asciidoc b/docs/detections/prebuilt-rules/rule-details/dns-over-https-enabled-via-registry.asciidoc index 358bc518c4..98a6f097aa 100644 --- a/docs/detections/prebuilt-rules/rule-details/dns-over-https-enabled-via-registry.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/dns-over-https-enabled-via-registry.asciidoc @@ -45,6 +45,20 @@ Identifies when a user enables DNS-over-HTTPS. This can be used to hide internet *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/domain-added-to-google-workspace-trusted-domains.asciidoc b/docs/detections/prebuilt-rules/rule-details/domain-added-to-google-workspace-trusted-domains.asciidoc index 55687c359d..44af72d3f0 100644 --- a/docs/detections/prebuilt-rules/rule-details/domain-added-to-google-workspace-trusted-domains.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/domain-added-to-google-workspace-trusted-domains.asciidoc @@ -82,7 +82,7 @@ This rule detects when a third-party domain is added to the list of trusted doma - 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. - Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. -- Implement security best practices [outlined](https://support.google.com/a/answer/7587183) by Google. +- Implement security best practices https://support.google.com/a/answer/7587183 by Google. - Determine 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). @@ -98,6 +98,14 @@ This rule detects when a third-party domain is added to the list of trusted doma - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/dumping-account-hashes-via-built-in-commands.asciidoc b/docs/detections/prebuilt-rules/rule-details/dumping-account-hashes-via-built-in-commands.asciidoc index 6e7bf05d70..aea195e6ef 100644 --- a/docs/detections/prebuilt-rules/rule-details/dumping-account-hashes-via-built-in-commands.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/dumping-account-hashes-via-built-in-commands.asciidoc @@ -41,6 +41,38 @@ Identifies the execution of macOS built-in commands used to dump user account ha *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### The following steps should be executed in order to add the Elastic Defend integration on a macOS 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, for MacOS it is recommended to select "Traditional Endpoints". +- 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/dumping-of-keychain-content-via-security-command.asciidoc b/docs/detections/prebuilt-rules/rule-details/dumping-of-keychain-content-via-security-command.asciidoc index a07e5e9cdd..529650874b 100644 --- a/docs/detections/prebuilt-rules/rule-details/dumping-of-keychain-content-via-security-command.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/dumping-of-keychain-content-via-security-command.asciidoc @@ -40,6 +40,38 @@ Adversaries may dump the content of the keychain storage data from a system to a *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### The following steps should be executed in order to add the Elastic Defend integration on a macOS 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, for MacOS it is recommended to select "Traditional Endpoints". +- 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/dynamic-linker-copy.asciidoc b/docs/detections/prebuilt-rules/rule-details/dynamic-linker-copy.asciidoc index 2dc8e6a542..ab483372f5 100644 --- a/docs/detections/prebuilt-rules/rule-details/dynamic-linker-copy.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/dynamic-linker-copy.asciidoc @@ -57,8 +57,8 @@ Adversaries may attempt to copy the dynamic linker binary and create a backup co The detection rule 'Dynamic Linker Copy' is designed to identify such abuse by monitoring for processes with names "cp" or "rsync" that involve copying the dynamic linker binary ("/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2") and modifying the "/etc/ld.so.preload" file. Additionally, the rule checks for the creation of new files with the "so" extension on Linux systems. By detecting these activities within a short time span (1 minute), the rule aims to alert security analysts to potential malicious behavior. > **Note**: -> This investigation guide uses the {security-guide}/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. -> This investigation guide uses {security-guide}/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. ### Possible investigation steps @@ -113,6 +113,38 @@ The detection rule 'Dynamic Linker Copy' is designed to identify such abuse by m - Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. - Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). +---------------------------------- + +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/elastic-agent-service-terminated.asciidoc b/docs/detections/prebuilt-rules/rule-details/elastic-agent-service-terminated.asciidoc index 370cf8146d..01ab36ad3d 100644 --- a/docs/detections/prebuilt-rules/rule-details/elastic-agent-service-terminated.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/elastic-agent-service-terminated.asciidoc @@ -40,6 +40,20 @@ Identifies the Elastic endpoint agent has stopped and is no longer running on th *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/emond-rules-creation-or-modification.asciidoc b/docs/detections/prebuilt-rules/rule-details/emond-rules-creation-or-modification.asciidoc index 89e8a444c8..1927c44a60 100644 --- a/docs/detections/prebuilt-rules/rule-details/emond-rules-creation-or-modification.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/emond-rules-creation-or-modification.asciidoc @@ -41,6 +41,38 @@ Identifies the creation or modification of the Event Monitor Daemon (emond) rule *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### The following steps should be executed in order to add the Elastic Defend integration on a macOS 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, for MacOS it is recommended to select "Traditional Endpoints". +- 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/enable-host-network-discovery-via-netsh.asciidoc b/docs/detections/prebuilt-rules/rule-details/enable-host-network-discovery-via-netsh.asciidoc index ee56aa1d20..fc70966b3d 100644 --- a/docs/detections/prebuilt-rules/rule-details/enable-host-network-discovery-via-netsh.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/enable-host-network-discovery-via-netsh.asciidoc @@ -80,6 +80,20 @@ Attackers can enable Network Discovery on the Windows firewall to find other sys - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/encrypting-files-with-winrar-or-7z.asciidoc b/docs/detections/prebuilt-rules/rule-details/encrypting-files-with-winrar-or-7z.asciidoc index f65076ae78..32d5288483 100644 --- a/docs/detections/prebuilt-rules/rule-details/encrypting-files-with-winrar-or-7z.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/encrypting-files-with-winrar-or-7z.asciidoc @@ -84,6 +84,20 @@ These steps are usually done in preparation for exfiltration, meaning the attack +---------------------------------- + +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/enumeration-command-spawned-via-wmiprvse.asciidoc b/docs/detections/prebuilt-rules/rule-details/enumeration-command-spawned-via-wmiprvse.asciidoc index 1208161295..b645714ab1 100644 --- a/docs/detections/prebuilt-rules/rule-details/enumeration-command-spawned-via-wmiprvse.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/enumeration-command-spawned-via-wmiprvse.asciidoc @@ -43,6 +43,20 @@ Identifies native Windows host and network enumeration commands spawned by the W *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/enumeration-of-administrator-accounts.asciidoc b/docs/detections/prebuilt-rules/rule-details/enumeration-of-administrator-accounts.asciidoc index 5574aa8c96..934e86daa6 100644 --- a/docs/detections/prebuilt-rules/rule-details/enumeration-of-administrator-accounts.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/enumeration-of-administrator-accounts.asciidoc @@ -82,6 +82,20 @@ This rule looks for the execution of the `net` and `wmic` utilities to enumerate - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/enumeration-of-kernel-modules-via-proc.asciidoc b/docs/detections/prebuilt-rules/rule-details/enumeration-of-kernel-modules-via-proc.asciidoc index 74d8b276ac..e8a8c9e1db 100644 --- a/docs/detections/prebuilt-rules/rule-details/enumeration-of-kernel-modules-via-proc.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/enumeration-of-kernel-modules-via-proc.asciidoc @@ -38,6 +38,29 @@ Loadable Kernel Modules (or LKMs) are pieces of code that can be loaded and unlo *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +This rule requires the use of the `auditd_manager` integration. `Auditd_manager` is a tool designed to simplify and enhance the management of the audit subsystem in Linux systems. It provides a user-friendly interface and automation capabilities for configuring and monitoring system auditing through the auditd daemon. With `auditd_manager`, administrators can easily define audit rules, track system events, and generate comprehensive audit reports, improving overall security and compliance in the system. The following steps should be executed in order to install and deploy `auditd_manager` on a Linux system. +``` +Kibana --> +Management --> +Integrations --> +Auditd Manager --> +Add Auditd Manager +``` +`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 to trigger, the following additional audit rules are required to be added to the integration: +``` +-w /proc/ -p r -k audit_proc +``` +Add the newly installed `auditd manager` to an agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/enumeration-of-kernel-modules.asciidoc b/docs/detections/prebuilt-rules/rule-details/enumeration-of-kernel-modules.asciidoc index 93113594d7..30e277d07b 100644 --- a/docs/detections/prebuilt-rules/rule-details/enumeration-of-kernel-modules.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/enumeration-of-kernel-modules.asciidoc @@ -38,6 +38,38 @@ Loadable Kernel Modules (or LKMs) are pieces of code that can be loaded and unlo *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/enumeration-of-privileged-local-groups-membership.asciidoc b/docs/detections/prebuilt-rules/rule-details/enumeration-of-privileged-local-groups-membership.asciidoc index 126558f510..ff8767c606 100644 --- a/docs/detections/prebuilt-rules/rule-details/enumeration-of-privileged-local-groups-membership.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/enumeration-of-privileged-local-groups-membership.asciidoc @@ -54,7 +54,7 @@ After successfully compromising an environment, attackers may try to gain situat This rule looks for the enumeration of privileged local groups' membership by suspicious processes, and excludes known legitimate utilities and programs installed. Attackers can use this information to decide the next steps of the attack, such as mapping targets for credential compromise and other post-exploitation activities. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps @@ -92,6 +92,36 @@ This rule looks for the enumeration of privileged local groups' membership by su - 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 + + +[source, markdown] +---------------------------------- + +The 'Audit Security Group Management' audit policy must be configured (Success). +Steps to implement the logging policy with with Advanced Audit Configuration: + +``` +Computer Configuration > +Policies > +Windows Settings > +Security Settings > +Advanced Audit Policies Configuration > +Audit Policies > +Account Management > +Audit Security Group Management (Success) +``` + +Microsoft introduced the https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4799 in this detection rule on Windows 10 and Windows Server 2016 or later operating systems. + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/enumeration-of-users-or-groups-via-built-in-commands.asciidoc b/docs/detections/prebuilt-rules/rule-details/enumeration-of-users-or-groups-via-built-in-commands.asciidoc index 4dbe25bc90..cd762ad32b 100644 --- a/docs/detections/prebuilt-rules/rule-details/enumeration-of-users-or-groups-via-built-in-commands.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/enumeration-of-users-or-groups-via-built-in-commands.asciidoc @@ -38,6 +38,38 @@ Identifies the execution of macOS built-in commands related to account or group *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### The following steps should be executed in order to add the Elastic Defend integration on a macOS 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, for MacOS it is recommended to select "Traditional Endpoints". +- 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/esxi-discovery-via-find.asciidoc b/docs/detections/prebuilt-rules/rule-details/esxi-discovery-via-find.asciidoc index e78a2e5b10..3fb4fb827e 100644 --- a/docs/detections/prebuilt-rules/rule-details/esxi-discovery-via-find.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/esxi-discovery-via-find.asciidoc @@ -40,6 +40,38 @@ Identifies instances where the 'find' command is started on a Linux system with *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/esxi-discovery-via-grep.asciidoc b/docs/detections/prebuilt-rules/rule-details/esxi-discovery-via-grep.asciidoc index 9a10db4a18..de2c9eb166 100644 --- a/docs/detections/prebuilt-rules/rule-details/esxi-discovery-via-grep.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/esxi-discovery-via-grep.asciidoc @@ -40,6 +40,38 @@ Identifies instances where a process named 'grep', 'egrep', or 'pgrep' is starte *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/esxi-timestomping-using-touch-command.asciidoc b/docs/detections/prebuilt-rules/rule-details/esxi-timestomping-using-touch-command.asciidoc index 4a407cda00..6ce16557ff 100644 --- a/docs/detections/prebuilt-rules/rule-details/esxi-timestomping-using-touch-command.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/esxi-timestomping-using-touch-command.asciidoc @@ -40,6 +40,38 @@ Identifies instances where the 'touch' command is executed on a Linux system wit *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/executable-file-creation-with-multiple-extensions.asciidoc b/docs/detections/prebuilt-rules/rule-details/executable-file-creation-with-multiple-extensions.asciidoc index a51363b7ea..193f508785 100644 --- a/docs/detections/prebuilt-rules/rule-details/executable-file-creation-with-multiple-extensions.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/executable-file-creation-with-multiple-extensions.asciidoc @@ -42,6 +42,20 @@ Masquerading can allow an adversary to evade defenses and better blend in with t *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/executable-masquerading-as-kernel-process.asciidoc b/docs/detections/prebuilt-rules/rule-details/executable-masquerading-as-kernel-process.asciidoc index 7979b2f45d..d184f22831 100644 --- a/docs/detections/prebuilt-rules/rule-details/executable-masquerading-as-kernel-process.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/executable-masquerading-as-kernel-process.asciidoc @@ -42,6 +42,38 @@ Monitors for kernel processes with associated process executable fields that are *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/execution-from-unusual-directory-command-line.asciidoc b/docs/detections/prebuilt-rules/rule-details/execution-from-unusual-directory-command-line.asciidoc index da9f68a2a6..d8dada1779 100644 --- a/docs/detections/prebuilt-rules/rule-details/execution-from-unusual-directory-command-line.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/execution-from-unusual-directory-command-line.asciidoc @@ -57,7 +57,7 @@ Identifies process execution from suspicious default Windows directories. This m This rule looks for the execution of scripts from unusual directories. Attackers can use system or application paths to hide malware and make the execution less suspicious. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps @@ -102,6 +102,20 @@ This rule looks for the execution of scripts from unusual directories. Attackers - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/execution-of-com-object-via-xwizard.asciidoc b/docs/detections/prebuilt-rules/rule-details/execution-of-com-object-via-xwizard.asciidoc index ce57d322e4..e38ed6c360 100644 --- a/docs/detections/prebuilt-rules/rule-details/execution-of-com-object-via-xwizard.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/execution-of-com-object-via-xwizard.asciidoc @@ -45,6 +45,20 @@ Windows Component Object Model (COM) is an inter-process communication (IPC) com *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/execution-via-electron-child-process-node-js-module.asciidoc b/docs/detections/prebuilt-rules/rule-details/execution-via-electron-child-process-node-js-module.asciidoc index 267f6da361..9deb6b4cfe 100644 --- a/docs/detections/prebuilt-rules/rule-details/execution-via-electron-child-process-node-js-module.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/execution-via-electron-child-process-node-js-module.asciidoc @@ -43,6 +43,38 @@ Identifies attempts to execute a child process from within the context of an Ele *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### The following steps should be executed in order to add the Elastic Defend integration on a macOS 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, for MacOS it is recommended to select "Traditional Endpoints". +- 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/execution-via-local-sxs-shared-module.asciidoc b/docs/detections/prebuilt-rules/rule-details/execution-via-local-sxs-shared-module.asciidoc index 056f51fcf7..ee60d3093c 100644 --- a/docs/detections/prebuilt-rules/rule-details/execution-via-local-sxs-shared-module.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/execution-via-local-sxs-shared-module.asciidoc @@ -54,6 +54,20 @@ Identifies the creation, change, or deletion of a DLL module within a Windows Sx The SxS DotLocal folder is a legitimate feature that can be abused to hijack standard modules loading order by forcing an executable on the same application.exe.local folder to load a malicious DLL module from the same directory. +---------------------------------- + +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/execution-via-mssql-xp-cmdshell-stored-procedure.asciidoc b/docs/detections/prebuilt-rules/rule-details/execution-via-mssql-xp-cmdshell-stored-procedure.asciidoc index 603bfd8fd8..c3ceed3f12 100644 --- a/docs/detections/prebuilt-rules/rule-details/execution-via-mssql-xp-cmdshell-stored-procedure.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/execution-via-mssql-xp-cmdshell-stored-procedure.asciidoc @@ -85,6 +85,20 @@ The xp_cmdshell procedure is disabled by default, but when used, it has the same - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/execution-via-tsclient-mountpoint.asciidoc b/docs/detections/prebuilt-rules/rule-details/execution-via-tsclient-mountpoint.asciidoc index fca7d51732..df2c721587 100644 --- a/docs/detections/prebuilt-rules/rule-details/execution-via-tsclient-mountpoint.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/execution-via-tsclient-mountpoint.asciidoc @@ -44,6 +44,20 @@ Identifies execution from the Remote Desktop Protocol (RDP) shared mountpoint ts *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/execution-with-explicit-credentials-via-scripting.asciidoc b/docs/detections/prebuilt-rules/rule-details/execution-with-explicit-credentials-via-scripting.asciidoc index cac7f21a4c..8a7c318bd8 100644 --- a/docs/detections/prebuilt-rules/rule-details/execution-with-explicit-credentials-via-scripting.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/execution-with-explicit-credentials-via-scripting.asciidoc @@ -42,6 +42,38 @@ Identifies execution of the security_authtrampoline process via a scripting inte *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### The following steps should be executed in order to add the Elastic Defend integration on a macOS 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, for MacOS it is recommended to select "Traditional Endpoints". +- 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/exporting-exchange-mailbox-via-powershell.asciidoc b/docs/detections/prebuilt-rules/rule-details/exporting-exchange-mailbox-via-powershell.asciidoc index 5bf72b323c..4a0dd2c67f 100644 --- a/docs/detections/prebuilt-rules/rule-details/exporting-exchange-mailbox-via-powershell.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/exporting-exchange-mailbox-via-powershell.asciidoc @@ -94,6 +94,20 @@ Attackers can abuse this functionality in preparation for exfiltrating contents, - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/external-user-added-to-google-workspace-group.asciidoc b/docs/detections/prebuilt-rules/rule-details/external-user-added-to-google-workspace-group.asciidoc index 2c39b4437b..d6063f04c5 100644 --- a/docs/detections/prebuilt-rules/rule-details/external-user-added-to-google-workspace-group.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/external-user-added-to-google-workspace-group.asciidoc @@ -85,7 +85,7 @@ This rule identifies when an external user account is added to an organization's - 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. - Reactivate multi-factor authentication for the user. - Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. -- Implement security defaults [provided by Google](https://cloud.google.com/security-command-center/docs/how-to-investigate-threats). +- Implement security defaults https://cloud.google.com/security-command-center/docs/how-to-investigate-threats. - Determine 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). @@ -101,6 +101,14 @@ This rule identifies when an external user account is added to an organization's - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/file-creation-execution-and-self-deletion-in-suspicious-directory.asciidoc b/docs/detections/prebuilt-rules/rule-details/file-creation-execution-and-self-deletion-in-suspicious-directory.asciidoc index df12059236..c92e7df0d8 100644 --- a/docs/detections/prebuilt-rules/rule-details/file-creation-execution-and-self-deletion-in-suspicious-directory.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/file-creation-execution-and-self-deletion-in-suspicious-directory.asciidoc @@ -38,6 +38,38 @@ This rule monitors for the creation of a file, followed by its execution and sel *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/file-deletion-via-shred.asciidoc b/docs/detections/prebuilt-rules/rule-details/file-deletion-via-shred.asciidoc index 07501b3d05..2a44ce88de 100644 --- a/docs/detections/prebuilt-rules/rule-details/file-deletion-via-shred.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/file-deletion-via-shred.asciidoc @@ -38,6 +38,38 @@ Malware or other files dropped or created on a system by an adversary may leave *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/file-made-immutable-by-chattr.asciidoc b/docs/detections/prebuilt-rules/rule-details/file-made-immutable-by-chattr.asciidoc index 41cd68043e..9f6614f3d4 100644 --- a/docs/detections/prebuilt-rules/rule-details/file-made-immutable-by-chattr.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/file-made-immutable-by-chattr.asciidoc @@ -41,6 +41,53 @@ Detects a file being made immutable using the chattr binary. Making a file immut *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Auditbeat + +### 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. + +#### 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. +- 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. +- 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. + +### Auditbeat Setup +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + +#### The following steps should be executed in order to add the Auditbeat on a Linux System: +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html. + +#### Custom Ingest Pipeline +For versions <8.2, you need to add a custom ingest pipeline to populate `event.ingested` with @timestamp for non-elastic-agent indexes, like auditbeats/filebeat/winlogbeat etc. For more details to add a custom ingest pipeline refer to the https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/file-permission-modification-in-writable-directory.asciidoc b/docs/detections/prebuilt-rules/rule-details/file-permission-modification-in-writable-directory.asciidoc index 1f854efa95..8446238b81 100644 --- a/docs/detections/prebuilt-rules/rule-details/file-permission-modification-in-writable-directory.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/file-permission-modification-in-writable-directory.asciidoc @@ -39,6 +39,50 @@ Identifies file permission modifications in common writable directories by a non *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Auditbeat + +### 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. + +#### 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. +- 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. +- 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. + +### Auditbeat Setup +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + +#### The following steps should be executed in order to add the Auditbeat on a Linux System: +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/file-transfer-or-listener-established-via-netcat.asciidoc b/docs/detections/prebuilt-rules/rule-details/file-transfer-or-listener-established-via-netcat.asciidoc index 0f945a6ef2..daf6b00b01 100644 --- a/docs/detections/prebuilt-rules/rule-details/file-transfer-or-listener-established-via-netcat.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/file-transfer-or-listener-established-via-netcat.asciidoc @@ -91,6 +91,50 @@ This rule identifies potential reverse shell or bind shell activity using Netcat - 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 + + +[source, markdown] +---------------------------------- + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Auditbeat + +### 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. + +#### 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. +- 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. +- 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. + +### Auditbeat Setup +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + +#### The following steps should be executed in order to add the Auditbeat on a Linux System: +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html. + + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/finder-sync-plugin-registered-and-enabled.asciidoc b/docs/detections/prebuilt-rules/rule-details/finder-sync-plugin-registered-and-enabled.asciidoc index 7714029b55..1b38f300fd 100644 --- a/docs/detections/prebuilt-rules/rule-details/finder-sync-plugin-registered-and-enabled.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/finder-sync-plugin-registered-and-enabled.asciidoc @@ -40,6 +40,38 @@ Finder Sync plugins enable users to extend Finder’s functionality by modifying *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### The following steps should be executed in order to add the Elastic Defend integration on a macOS 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, for MacOS it is recommended to select "Traditional Endpoints". +- 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/first-occurrence-of-okta-user-session-started-via-proxy.asciidoc b/docs/detections/prebuilt-rules/rule-details/first-occurrence-of-okta-user-session-started-via-proxy.asciidoc index c42e1e4e1b..667f0e69e6 100644 --- a/docs/detections/prebuilt-rules/rule-details/first-occurrence-of-okta-user-session-started-via-proxy.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/first-occurrence-of-okta-user-session-started-via-proxy.asciidoc @@ -76,6 +76,14 @@ This rule detects the first occurrence of an Okta user session started via a pro ## Setup ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/first-time-seen-aws-secret-value-accessed-in-secrets-manager.asciidoc b/docs/detections/prebuilt-rules/rule-details/first-time-seen-aws-secret-value-accessed-in-secrets-manager.asciidoc index bf58ea2539..526747da44 100644 --- a/docs/detections/prebuilt-rules/rule-details/first-time-seen-aws-secret-value-accessed-in-secrets-manager.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/first-time-seen-aws-secret-value-accessed-in-secrets-manager.asciidoc @@ -54,7 +54,7 @@ An adversary equipped with compromised credentials may attempt to access the sec AWS Secrets Manager is a service that enables the replacement of hardcoded credentials in code, including passwords, with an API call to Secrets Manager to retrieve the secret programmatically. -This rule looks for the retrieval of credentials using `GetSecretValue` action in Secrets Manager programmatically. This is a {security-guide}/security/master/rules-ui-create.html#create-new-terms-rule[New Terms] rule indicating this is the first time a specific user identity has successfuly retrieved a secret value from Secrets Manager. +This rule looks for the retrieval of credentials using `GetSecretValue` action in Secrets Manager programmatically. This is a https://www.elastic.co/guide/en/security/master/rules-ui-create.html#create-new-terms-rule rule indicating this is the first time a specific user identity has successfuly retrieved a secret value from Secrets Manager. #### Possible investigation steps @@ -90,12 +90,20 @@ This rule looks for the retrieval of credentials using `GetSecretValue` action i - 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 [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS. +- Implement security best practices https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/ 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 + + +[source, markdown] +---------------------------------- +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/first-time-seen-driver-loaded.asciidoc b/docs/detections/prebuilt-rules/rule-details/first-time-seen-driver-loaded.asciidoc index 995a424d7f..29013e6974 100644 --- a/docs/detections/prebuilt-rules/rule-details/first-time-seen-driver-loaded.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/first-time-seen-driver-loaded.asciidoc @@ -55,12 +55,12 @@ A driver is a software component that allows the operating system to communicate Attackers may exploit known good but vulnerable drivers to execute code in their context because once an attacker can execute code in the kernel, security tools can no longer effectively protect the host. They can leverage these drivers to tamper, bypass and terminate security software, elevate privileges, create persistence mechanisms, and disable operating system protections and monitoring features. Attackers were seen in the wild conducting these actions before acting on their objectives, such as ransomware. -Read the complete research on "Stopping Vulnerable Driver Attacks" done by Elastic Security Labs [here](https://www.elastic.co/kr/security-labs/stopping-vulnerable-driver-attacks). +Read the complete research on "Stopping Vulnerable Driver Attacks" done by Elastic Security Labs https://www.elastic.co/kr/security-labs/stopping-vulnerable-driver-attacks. This rule identifies the load of a driver with an original file name and signature values observed for the first time during the last 30 days. This rule type can help baseline drivers installation within your environment. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps diff --git a/docs/detections/prebuilt-rules/rule-details/first-time-seen-google-workspace-oauth-login-from-third-party-application.asciidoc b/docs/detections/prebuilt-rules/rule-details/first-time-seen-google-workspace-oauth-login-from-third-party-application.asciidoc index 34a09a1e3d..c934d889a8 100644 --- a/docs/detections/prebuilt-rules/rule-details/first-time-seen-google-workspace-oauth-login-from-third-party-application.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/first-time-seen-google-workspace-oauth-login-from-third-party-application.asciidoc @@ -59,6 +59,14 @@ Detects the first time a third-party application logs in and authenticated with - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/firsttime-seen-account-performing-dcsync.asciidoc b/docs/detections/prebuilt-rules/rule-details/firsttime-seen-account-performing-dcsync.asciidoc index 4a9247a12e..9f83d2968f 100644 --- a/docs/detections/prebuilt-rules/rule-details/firsttime-seen-account-performing-dcsync.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/firsttime-seen-account-performing-dcsync.asciidoc @@ -65,7 +65,7 @@ Active Directory data consists of objects that have properties, or attributes. E Adversaries can use the DCSync technique that uses Windows Domain Controller's API to simulate the replication process from a remote domain controller, compromising major credential material such as the Kerberos krbtgt keys that are used legitimately for creating tickets, but also for forging tickets by attackers. This attack requires some extended privileges to succeed (DS-Replication-Get-Changes and DS-Replication-Get-Changes-All), which are granted by default to members of the Administrators, Domain Admins, Enterprise Admins, and Domain Controllers groups. Privileged accounts can be abused to grant controlled objects the right to DCsync/Replicate. -More details can be found on [Threat Hunter Playbook](https://threathunterplaybook.com/library/windows/active_directory_replication.html?highlight=dcsync#directory-replication-services-auditing) and [The Hacker Recipes](https://www.thehacker.recipes/ad/movement/credentials/dumping/dcsync). +More details can be found on https://threathunterplaybook.com/library/windows/active_directory_replication.html?highlight=dcsync#directory-replication-services-auditing and https://www.thehacker.recipes/ad/movement/credentials/dumping/dcsync. This rule monitors for when a Windows Event ID 4662 (Operation was performed on an Active Directory object) with the access mask 0x100 (Control Access) and properties that contain at least one of the following or their equivalent Schema-Id-GUID (DS-Replication-Get-Changes, DS-Replication-Get-Changes-All, DS-Replication-Get-Changes-In-Filtered-Set) is seen in the environment for the first time in the last 15 days. @@ -93,6 +93,28 @@ This rule monitors for when a Windows Event ID 4662 (Operation was performed on - 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 + + +[source, markdown] +---------------------------------- + +The 'Audit Directory Service Access' 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 Access (Success,Failure) +``` + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/forwarded-google-workspace-security-alert.asciidoc b/docs/detections/prebuilt-rules/rule-details/forwarded-google-workspace-security-alert.asciidoc index 23fa88904b..bc641b555b 100644 --- a/docs/detections/prebuilt-rules/rule-details/forwarded-google-workspace-security-alert.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/forwarded-google-workspace-security-alert.asciidoc @@ -51,6 +51,14 @@ This is a promotion rule for Google Workspace security events, which are alertab Consult vendor documentation on interpreting specific events. ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/gcp-firewall-rule-creation.asciidoc b/docs/detections/prebuilt-rules/rule-details/gcp-firewall-rule-creation.asciidoc index 483866214b..e8f36ecd89 100644 --- a/docs/detections/prebuilt-rules/rule-details/gcp-firewall-rule-creation.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/gcp-firewall-rule-creation.asciidoc @@ -50,6 +50,14 @@ Identifies when a firewall rule is created in Google Cloud Platform (GCP) for Vi ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/gcp-firewall-rule-deletion.asciidoc b/docs/detections/prebuilt-rules/rule-details/gcp-firewall-rule-deletion.asciidoc index 1142bcb2ab..3cd1004733 100644 --- a/docs/detections/prebuilt-rules/rule-details/gcp-firewall-rule-deletion.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/gcp-firewall-rule-deletion.asciidoc @@ -50,6 +50,14 @@ Identifies when a firewall rule is deleted in Google Cloud Platform (GCP) for Vi ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/gcp-firewall-rule-modification.asciidoc b/docs/detections/prebuilt-rules/rule-details/gcp-firewall-rule-modification.asciidoc index 4d76276ac0..9e48d8da15 100644 --- a/docs/detections/prebuilt-rules/rule-details/gcp-firewall-rule-modification.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/gcp-firewall-rule-modification.asciidoc @@ -50,6 +50,14 @@ Identifies when a firewall rule is modified in Google Cloud Platform (GCP) for V ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/gcp-iam-custom-role-creation.asciidoc b/docs/detections/prebuilt-rules/rule-details/gcp-iam-custom-role-creation.asciidoc index 9dd08f1cae..5b7dc8efc3 100644 --- a/docs/detections/prebuilt-rules/rule-details/gcp-iam-custom-role-creation.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/gcp-iam-custom-role-creation.asciidoc @@ -49,6 +49,14 @@ Identifies an Identity and Access Management (IAM) custom role creation in Googl ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/gcp-iam-role-deletion.asciidoc b/docs/detections/prebuilt-rules/rule-details/gcp-iam-role-deletion.asciidoc index bc883d4bd1..23b8794a5a 100644 --- a/docs/detections/prebuilt-rules/rule-details/gcp-iam-role-deletion.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/gcp-iam-role-deletion.asciidoc @@ -49,6 +49,14 @@ Identifies an Identity and Access Management (IAM) role deletion in Google Cloud ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/gcp-iam-service-account-key-deletion.asciidoc b/docs/detections/prebuilt-rules/rule-details/gcp-iam-service-account-key-deletion.asciidoc index ccece3ab62..aa9e0c825f 100644 --- a/docs/detections/prebuilt-rules/rule-details/gcp-iam-service-account-key-deletion.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/gcp-iam-service-account-key-deletion.asciidoc @@ -50,6 +50,14 @@ Identifies the deletion of an Identity and Access Management (IAM) service accou ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/gcp-logging-bucket-deletion.asciidoc b/docs/detections/prebuilt-rules/rule-details/gcp-logging-bucket-deletion.asciidoc index 98080df83a..6bfeda3abc 100644 --- a/docs/detections/prebuilt-rules/rule-details/gcp-logging-bucket-deletion.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/gcp-logging-bucket-deletion.asciidoc @@ -50,6 +50,14 @@ Identifies a Logging bucket deletion in Google Cloud Platform (GCP). Log buckets ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/gcp-logging-sink-deletion.asciidoc b/docs/detections/prebuilt-rules/rule-details/gcp-logging-sink-deletion.asciidoc index df69a232ca..3d0a92a0fd 100644 --- a/docs/detections/prebuilt-rules/rule-details/gcp-logging-sink-deletion.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/gcp-logging-sink-deletion.asciidoc @@ -49,6 +49,14 @@ Identifies a Logging sink deletion in Google Cloud Platform (GCP). Every time a ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/gcp-logging-sink-modification.asciidoc b/docs/detections/prebuilt-rules/rule-details/gcp-logging-sink-modification.asciidoc index f55ad399b4..15418d12b2 100644 --- a/docs/detections/prebuilt-rules/rule-details/gcp-logging-sink-modification.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/gcp-logging-sink-modification.asciidoc @@ -49,6 +49,14 @@ Identifies a modification to a Logging sink in Google Cloud Platform (GCP). Logg ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/gcp-pub-sub-subscription-creation.asciidoc b/docs/detections/prebuilt-rules/rule-details/gcp-pub-sub-subscription-creation.asciidoc index fd938f3a21..5fd50bc55c 100644 --- a/docs/detections/prebuilt-rules/rule-details/gcp-pub-sub-subscription-creation.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/gcp-pub-sub-subscription-creation.asciidoc @@ -49,6 +49,14 @@ Identifies the creation of a subscription in Google Cloud Platform (GCP). In GCP ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/gcp-pub-sub-subscription-deletion.asciidoc b/docs/detections/prebuilt-rules/rule-details/gcp-pub-sub-subscription-deletion.asciidoc index 5680e414e4..f04c4d4d44 100644 --- a/docs/detections/prebuilt-rules/rule-details/gcp-pub-sub-subscription-deletion.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/gcp-pub-sub-subscription-deletion.asciidoc @@ -49,6 +49,14 @@ Identifies the deletion of a subscription in Google Cloud Platform (GCP). In GCP ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/gcp-pub-sub-topic-creation.asciidoc b/docs/detections/prebuilt-rules/rule-details/gcp-pub-sub-topic-creation.asciidoc index 8bed9079a8..17dc5c7d7d 100644 --- a/docs/detections/prebuilt-rules/rule-details/gcp-pub-sub-topic-creation.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/gcp-pub-sub-topic-creation.asciidoc @@ -49,6 +49,14 @@ Identifies the creation of a topic in Google Cloud Platform (GCP). In GCP, the p ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/gcp-pub-sub-topic-deletion.asciidoc b/docs/detections/prebuilt-rules/rule-details/gcp-pub-sub-topic-deletion.asciidoc index 2f93815def..08658c89f7 100644 --- a/docs/detections/prebuilt-rules/rule-details/gcp-pub-sub-topic-deletion.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/gcp-pub-sub-topic-deletion.asciidoc @@ -49,6 +49,14 @@ Identifies the deletion of a topic in Google Cloud Platform (GCP). In GCP, the p ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/gcp-service-account-creation.asciidoc b/docs/detections/prebuilt-rules/rule-details/gcp-service-account-creation.asciidoc index 4ec9a4a6ef..f5055360a0 100644 --- a/docs/detections/prebuilt-rules/rule-details/gcp-service-account-creation.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/gcp-service-account-creation.asciidoc @@ -49,6 +49,14 @@ Identifies when a new service account is created in Google Cloud Platform (GCP). ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/gcp-service-account-deletion.asciidoc b/docs/detections/prebuilt-rules/rule-details/gcp-service-account-deletion.asciidoc index 293bda6650..8732aadae6 100644 --- a/docs/detections/prebuilt-rules/rule-details/gcp-service-account-deletion.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/gcp-service-account-deletion.asciidoc @@ -49,6 +49,14 @@ Identifies when a service account is deleted in Google Cloud Platform (GCP). A s ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/gcp-service-account-disabled.asciidoc b/docs/detections/prebuilt-rules/rule-details/gcp-service-account-disabled.asciidoc index bd0e54748c..c0c5e58360 100644 --- a/docs/detections/prebuilt-rules/rule-details/gcp-service-account-disabled.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/gcp-service-account-disabled.asciidoc @@ -49,6 +49,14 @@ Identifies when a service account is disabled in Google Cloud Platform (GCP). A ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/gcp-service-account-key-creation.asciidoc b/docs/detections/prebuilt-rules/rule-details/gcp-service-account-key-creation.asciidoc index 4e2ef5fc3c..3ff433e881 100644 --- a/docs/detections/prebuilt-rules/rule-details/gcp-service-account-key-creation.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/gcp-service-account-key-creation.asciidoc @@ -50,6 +50,14 @@ Identifies when a new key is created for a service account in Google Cloud Platf ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/gcp-storage-bucket-configuration-modification.asciidoc b/docs/detections/prebuilt-rules/rule-details/gcp-storage-bucket-configuration-modification.asciidoc index 362d6fd8b7..0b554b1ce3 100644 --- a/docs/detections/prebuilt-rules/rule-details/gcp-storage-bucket-configuration-modification.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/gcp-storage-bucket-configuration-modification.asciidoc @@ -49,6 +49,14 @@ Identifies when the configuration is modified for a storage bucket in Google Clo ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/gcp-storage-bucket-deletion.asciidoc b/docs/detections/prebuilt-rules/rule-details/gcp-storage-bucket-deletion.asciidoc index baa04dc345..41d4a022f5 100644 --- a/docs/detections/prebuilt-rules/rule-details/gcp-storage-bucket-deletion.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/gcp-storage-bucket-deletion.asciidoc @@ -48,6 +48,14 @@ Identifies when a Google Cloud Platform (GCP) storage bucket is deleted. An adve ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/gcp-storage-bucket-permissions-modification.asciidoc b/docs/detections/prebuilt-rules/rule-details/gcp-storage-bucket-permissions-modification.asciidoc index 847cafaa78..186abfc347 100644 --- a/docs/detections/prebuilt-rules/rule-details/gcp-storage-bucket-permissions-modification.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/gcp-storage-bucket-permissions-modification.asciidoc @@ -49,6 +49,14 @@ Identifies when the Identity and Access Management (IAM) permissions are modifie ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/gcp-virtual-private-cloud-network-deletion.asciidoc b/docs/detections/prebuilt-rules/rule-details/gcp-virtual-private-cloud-network-deletion.asciidoc index d95bc6d53c..4671b7fd0b 100644 --- a/docs/detections/prebuilt-rules/rule-details/gcp-virtual-private-cloud-network-deletion.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/gcp-virtual-private-cloud-network-deletion.asciidoc @@ -49,6 +49,14 @@ Identifies when a Virtual Private Cloud (VPC) network is deleted in Google Cloud ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/gcp-virtual-private-cloud-route-creation.asciidoc b/docs/detections/prebuilt-rules/rule-details/gcp-virtual-private-cloud-route-creation.asciidoc index 109afd60a2..27137a0da2 100644 --- a/docs/detections/prebuilt-rules/rule-details/gcp-virtual-private-cloud-route-creation.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/gcp-virtual-private-cloud-route-creation.asciidoc @@ -50,6 +50,14 @@ Identifies when a virtual private cloud (VPC) route is created in Google Cloud P ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/gcp-virtual-private-cloud-route-deletion.asciidoc b/docs/detections/prebuilt-rules/rule-details/gcp-virtual-private-cloud-route-deletion.asciidoc index c0da77fbc0..97b9258ce3 100644 --- a/docs/detections/prebuilt-rules/rule-details/gcp-virtual-private-cloud-route-deletion.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/gcp-virtual-private-cloud-route-deletion.asciidoc @@ -50,6 +50,14 @@ Identifies when a Virtual Private Cloud (VPC) route is deleted in Google Cloud P ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/google-drive-ownership-transferred-via-google-workspace.asciidoc b/docs/detections/prebuilt-rules/rule-details/google-drive-ownership-transferred-via-google-workspace.asciidoc index 317d90a9f6..61af2b4fa0 100644 --- a/docs/detections/prebuilt-rules/rule-details/google-drive-ownership-transferred-via-google-workspace.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/google-drive-ownership-transferred-via-google-workspace.asciidoc @@ -81,7 +81,7 @@ This rule identifies when the ownership of a shared drive within a Google Worksp - 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. - Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. -- Implement security best practices [outlined](https://support.google.com/a/answer/7587183) by Google. +- Implement security best practices https://support.google.com/a/answer/7587183 by Google. - Determine 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). @@ -97,6 +97,14 @@ This rule identifies when the ownership of a shared drive within a Google Worksp - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/google-workspace-2sv-policy-disabled.asciidoc b/docs/detections/prebuilt-rules/rule-details/google-workspace-2sv-policy-disabled.asciidoc index f82feabb61..5679ba5bba 100644 --- a/docs/detections/prebuilt-rules/rule-details/google-workspace-2sv-policy-disabled.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/google-workspace-2sv-policy-disabled.asciidoc @@ -83,7 +83,7 @@ This rule detects when a 2SV policy is disabled in Google Workspace. - 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. - Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. -- Implement security best practices [outlined](https://support.google.com/a/answer/7587183) by Google. +- Implement security best practices https://support.google.com/a/answer/7587183 by Google. - Determine 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). @@ -99,6 +99,14 @@ This rule detects when a 2SV policy is disabled in Google Workspace. - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/google-workspace-admin-role-assigned-to-a-user.asciidoc b/docs/detections/prebuilt-rules/rule-details/google-workspace-admin-role-assigned-to-a-user.asciidoc index 764d70dd8d..5b3dce565c 100644 --- a/docs/detections/prebuilt-rules/rule-details/google-workspace-admin-role-assigned-to-a-user.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/google-workspace-admin-role-assigned-to-a-user.asciidoc @@ -87,7 +87,7 @@ This rule identifies when a Google Workspace administrative role is assigned to - 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. - Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. -- Implement security best practices [outlined](https://support.google.com/a/answer/7587183) by Google. +- Implement security best practices https://support.google.com/a/answer/7587183 by Google. - Determine 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). @@ -103,6 +103,14 @@ This rule identifies when a Google Workspace administrative role is assigned to - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/google-workspace-admin-role-deletion.asciidoc b/docs/detections/prebuilt-rules/rule-details/google-workspace-admin-role-deletion.asciidoc index 839c74c47b..590a85e7b6 100644 --- a/docs/detections/prebuilt-rules/rule-details/google-workspace-admin-role-deletion.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/google-workspace-admin-role-deletion.asciidoc @@ -82,7 +82,7 @@ This rule identifies when a Google Workspace administrative role is deleted with - 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. - Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. -- Implement security best practices [outlined](https://support.google.com/a/answer/7587183) by Google. +- Implement security best practices https://support.google.com/a/answer/7587183 by Google. - Determine 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). @@ -98,6 +98,14 @@ This rule identifies when a Google Workspace administrative role is deleted with - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/google-workspace-api-access-granted-via-domain-wide-delegation-of-authority.asciidoc b/docs/detections/prebuilt-rules/rule-details/google-workspace-api-access-granted-via-domain-wide-delegation-of-authority.asciidoc index 974dc3bcd8..952356d54a 100644 --- a/docs/detections/prebuilt-rules/rule-details/google-workspace-api-access-granted-via-domain-wide-delegation-of-authority.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/google-workspace-api-access-granted-via-domain-wide-delegation-of-authority.asciidoc @@ -84,7 +84,7 @@ This rule identifies when an application is authorized API client access. - 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. - Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. -- Implement security best practices [outlined](https://support.google.com/a/answer/7587183) by Google. +- Implement security best practices https://support.google.com/a/answer/7587183 by Google. - Determine 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). @@ -100,6 +100,14 @@ This rule identifies when an application is authorized API client access. - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/google-workspace-bitlocker-setting-disabled.asciidoc b/docs/detections/prebuilt-rules/rule-details/google-workspace-bitlocker-setting-disabled.asciidoc index 33d128a036..d8ca2396a4 100644 --- a/docs/detections/prebuilt-rules/rule-details/google-workspace-bitlocker-setting-disabled.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/google-workspace-bitlocker-setting-disabled.asciidoc @@ -80,7 +80,7 @@ This rule identifies a user with administrative privileges and access to the adm - 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. - Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. -- Implement security best practices [outlined](https://support.google.com/a/answer/7587183) by Google. +- Implement security best practices https://support.google.com/a/answer/7587183 by Google. - Determine 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). @@ -96,6 +96,14 @@ This rule identifies a user with administrative privileges and access to the adm - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/google-workspace-custom-admin-role-created.asciidoc b/docs/detections/prebuilt-rules/rule-details/google-workspace-custom-admin-role-created.asciidoc index 6ac045f769..8c4557bc71 100644 --- a/docs/detections/prebuilt-rules/rule-details/google-workspace-custom-admin-role-created.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/google-workspace-custom-admin-role-created.asciidoc @@ -87,7 +87,7 @@ This rule identifies when a Google Workspace administrative role is added within - 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. - Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. -- Implement security best practices [outlined](https://support.google.com/a/answer/7587183) by Google. +- Implement security best practices https://support.google.com/a/answer/7587183 by Google. - Determine 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). @@ -103,6 +103,14 @@ This rule identifies when a Google Workspace administrative role is added within - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/google-workspace-custom-gmail-route-created-or-modified.asciidoc b/docs/detections/prebuilt-rules/rule-details/google-workspace-custom-gmail-route-created-or-modified.asciidoc index c64dec9775..9cc1858e9b 100644 --- a/docs/detections/prebuilt-rules/rule-details/google-workspace-custom-gmail-route-created-or-modified.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/google-workspace-custom-gmail-route-created-or-modified.asciidoc @@ -80,7 +80,7 @@ This rule identifies the creation of a custom global Gmail route by an administr - 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. - Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. -- Implement security best practices [outlined](https://support.google.com/a/answer/7587183) by Google. +- Implement security best practices https://support.google.com/a/answer/7587183 by Google. - Determine 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). @@ -96,6 +96,14 @@ This rule identifies the creation of a custom global Gmail route by an administr - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/google-workspace-drive-encryption-key-s-accessed-from-anonymous-user.asciidoc b/docs/detections/prebuilt-rules/rule-details/google-workspace-drive-encryption-key-s-accessed-from-anonymous-user.asciidoc index be1a96c214..0a3b52778b 100644 --- a/docs/detections/prebuilt-rules/rule-details/google-workspace-drive-encryption-key-s-accessed-from-anonymous-user.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/google-workspace-drive-encryption-key-s-accessed-from-anonymous-user.asciidoc @@ -55,6 +55,14 @@ Detects when an external (anonymous) user has viewed, copied or downloaded an en - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/google-workspace-mfa-enforcement-disabled.asciidoc b/docs/detections/prebuilt-rules/rule-details/google-workspace-mfa-enforcement-disabled.asciidoc index 69e30484da..00bb8ddf25 100644 --- a/docs/detections/prebuilt-rules/rule-details/google-workspace-mfa-enforcement-disabled.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/google-workspace-mfa-enforcement-disabled.asciidoc @@ -54,7 +54,7 @@ Multi-factor authentication is a process in which users are prompted during the If you only use a password to authenticate a user, it leaves an insecure vector for attack. If the password is weak or has been exposed elsewhere, an attacker could be using it to gain access. When you require a second form of authentication, security is increased because this additional factor isn't something that's easy for an attacker to obtain or duplicate. -For more information about using MFA in Google Workspace, access the [official documentation](https://support.google.com/a/answer/175197). +For more information about using MFA in Google Workspace, access the https://support.google.com/a/answer/175197. This rule identifies the disabling of MFA enforcement in Google Workspace. This modification weakens the security of the accounts and can lead to the compromise of accounts and other assets. @@ -83,7 +83,7 @@ This rule identifies the disabling of MFA enforcement in Google Workspace. This - 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. - Reactivate the multi-factor authentication enforcement. - Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. -- Implement security best practices [outlined](https://support.google.com/a/answer/7587183) by Google. +- Implement security best practices https://support.google.com/a/answer/7587183 by Google. - Determine 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). @@ -100,6 +100,14 @@ This rule identifies the disabling of MFA enforcement in Google Workspace. This - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/google-workspace-object-copied-from-external-drive-and-access-granted-to-custom-application.asciidoc b/docs/detections/prebuilt-rules/rule-details/google-workspace-object-copied-from-external-drive-and-access-granted-to-custom-application.asciidoc index b7ee2b1990..22e33948b7 100644 --- a/docs/detections/prebuilt-rules/rule-details/google-workspace-object-copied-from-external-drive-and-access-granted-to-custom-application.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/google-workspace-object-copied-from-external-drive-and-access-granted-to-custom-application.asciidoc @@ -85,7 +85,7 @@ This rule aims to detect when a user copies an external Drive object to their Dr - Resetting passwords will revoke OAuth tokens which could have been stolen. - Reactivate multi-factor authentication for the user. - Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. -- Implement security defaults [provided by Google](https://cloud.google.com/security-command-center/docs/how-to-investigate-threats). +- Implement security defaults https://cloud.google.com/security-command-center/docs/how-to-investigate-threats. - Determine 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). @@ -101,6 +101,14 @@ This rule aims to detect when a user copies an external Drive object to their Dr - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/google-workspace-password-policy-modified.asciidoc b/docs/detections/prebuilt-rules/rule-details/google-workspace-password-policy-modified.asciidoc index 263a4bec44..943b5e24ce 100644 --- a/docs/detections/prebuilt-rules/rule-details/google-workspace-password-policy-modified.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/google-workspace-password-policy-modified.asciidoc @@ -83,7 +83,7 @@ This rule detects when a Google Workspace password policy is modified to decreas - 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. - Reactivate multi-factor authentication for the user. - Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. -- Implement security best practices [outlined](https://support.google.com/a/answer/7587183) by Google. +- Implement security best practices https://support.google.com/a/answer/7587183 by Google. - Determine 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). @@ -99,6 +99,14 @@ This rule detects when a Google Workspace password policy is modified to decreas - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Google Workspace Fleet integration, the Filebeat module, or data that's similarly structured is required for this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/google-workspace-restrictions-for-google-marketplace-modified-to-allow-any-app.asciidoc b/docs/detections/prebuilt-rules/rule-details/google-workspace-restrictions-for-google-marketplace-modified-to-allow-any-app.asciidoc index 95de6bcc91..510229ff5e 100644 --- a/docs/detections/prebuilt-rules/rule-details/google-workspace-restrictions-for-google-marketplace-modified-to-allow-any-app.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/google-workspace-restrictions-for-google-marketplace-modified-to-allow-any-app.asciidoc @@ -87,7 +87,7 @@ This rule identifies when the global allow-all setting is enabled for Google Wor - 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. - Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. -- Implement security best practices [outlined](https://support.google.com/a/answer/7587183) by Google. +- Implement security best practices https://support.google.com/a/answer/7587183 by Google. - Determine 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). @@ -103,6 +103,14 @@ This rule identifies when the global allow-all setting is enabled for Google Wor - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/google-workspace-role-modified.asciidoc b/docs/detections/prebuilt-rules/rule-details/google-workspace-role-modified.asciidoc index ad2ba662db..125d164acb 100644 --- a/docs/detections/prebuilt-rules/rule-details/google-workspace-role-modified.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/google-workspace-role-modified.asciidoc @@ -89,7 +89,7 @@ This rule identifies when a Google Workspace role is modified. - 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. - Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. -- Implement security best practices [outlined](https://support.google.com/a/answer/7587183) by Google. +- Implement security best practices https://support.google.com/a/answer/7587183 by Google. - Determine 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). @@ -105,6 +105,14 @@ This rule identifies when a Google Workspace role is modified. - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/google-workspace-suspended-user-account-renewed.asciidoc b/docs/detections/prebuilt-rules/rule-details/google-workspace-suspended-user-account-renewed.asciidoc index d7778e9bf1..5ef13d1fd7 100644 --- a/docs/detections/prebuilt-rules/rule-details/google-workspace-suspended-user-account-renewed.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/google-workspace-suspended-user-account-renewed.asciidoc @@ -55,6 +55,14 @@ Detects when a previously suspended user's account is renewed in Google Workspac - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/google-workspace-user-organizational-unit-changed.asciidoc b/docs/detections/prebuilt-rules/rule-details/google-workspace-user-organizational-unit-changed.asciidoc index 5d99ddb835..29b33e0582 100644 --- a/docs/detections/prebuilt-rules/rule-details/google-workspace-user-organizational-unit-changed.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/google-workspace-user-organizational-unit-changed.asciidoc @@ -86,7 +86,7 @@ This rule identifies when a user has been moved to a different organizational un - 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. - Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. -- Implement security best practices [outlined](https://support.google.com/a/answer/7587183) by Google. +- Implement security best practices https://support.google.com/a/answer/7587183 by Google. - Determine 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). @@ -102,6 +102,14 @@ This rule identifies when a user has been moved to a different organizational un - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/group-policy-abuse-for-privilege-addition.asciidoc b/docs/detections/prebuilt-rules/rule-details/group-policy-abuse-for-privilege-addition.asciidoc index 0602c7c263..2cb19159a7 100644 --- a/docs/detections/prebuilt-rules/rule-details/group-policy-abuse-for-privilege-addition.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/group-policy-abuse-for-privilege-addition.asciidoc @@ -79,6 +79,28 @@ Group Policy Objects (GPOs) can be used to add rights and/or modify Group Member - Check if other GPOs have suspicious scripts attached. +---------------------------------- + +==== Setup + + +[source, markdown] +---------------------------------- + +The 'Audit Directory Service Changes' audit policy must be configured (Success Failure). +Steps to implement the logging policy with 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) +``` + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/high-mean-of-process-arguments-in-an-rdp-session.asciidoc b/docs/detections/prebuilt-rules/rule-details/high-mean-of-process-arguments-in-an-rdp-session.asciidoc index 06a8675314..969dddfcfd 100644 --- a/docs/detections/prebuilt-rules/rule-details/high-mean-of-process-arguments-in-an-rdp-session.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/high-mean-of-process-arguments-in-an-rdp-session.asciidoc @@ -40,6 +40,37 @@ A machine learning job has detected unusually high number of process arguments i *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- +The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration. + +### Lateral Movement Detection Setup +The Lateral Movement Detection integration detects lateral movement activity by identifying abnormalities in file and Windows RDP events. Anomalies are detected using Elastic's Anomaly Detection feature. + +#### Prerequisite Requirements: +- Fleet is required for Lateral Movement Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html. +- Windows RDP process events collected by the https://docs.elastic.co/en/integrations/endpoint integration. +- To install Elastic Defend, refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html. + +#### The following steps should be executed to install assets associated with the Lateral Movement Detection integration: +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Lateral Movement Detection and select the integration to see more details about it. +- Under Settings, click Install Lateral Movement Detection assets and follow the prompts to install the assets. + +#### Anomaly Detection Setup +Before you can enable rules for Lateral Movement Detection, you'll need to enable the corresponding Anomaly Detection jobs. +- Before enabling the Anomaly Detection jobs, confirm that the Pivot Transform asset is installed and actively gathering data in the destination index `ml-rdp-lmd`. +- Go to the Kibana homepage. Under Analytics, click Machine Learning. +- Under Anomaly Detection, click Jobs, and then click "Create job". Select the Data View containing your transformed RDP process data i.e.`ml-rdp-lmd`. +- If the selected Data View contains events that match the query in https://github.com/elastic/integrations/blob/main/packages/lmd/kibana/ml_module/lmd-ml.json configuration file, you will see a card for Lateral Movement Detection under "Use preconfigured jobs". +- Keep the default settings and click "Create jobs" to start the anomaly detection jobs and datafeeds. + +---------------------------------- + *Framework*: MITRE ATT&CK^TM^ * Tactic: diff --git a/docs/detections/prebuilt-rules/rule-details/high-mean-of-rdp-session-duration.asciidoc b/docs/detections/prebuilt-rules/rule-details/high-mean-of-rdp-session-duration.asciidoc index f21dff41c6..454e9fca58 100644 --- a/docs/detections/prebuilt-rules/rule-details/high-mean-of-rdp-session-duration.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/high-mean-of-rdp-session-duration.asciidoc @@ -40,6 +40,37 @@ A machine learning job has detected unusually high mean of RDP session duration. *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- +The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration. + +### Lateral Movement Detection Setup +The Lateral Movement Detection integration detects lateral movement activity by identifying abnormalities in file and Windows RDP events. Anomalies are detected using Elastic's Anomaly Detection feature. + +#### Prerequisite Requirements: +- Fleet is required for Lateral Movement Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html. +- Windows RDP process events collected by the https://docs.elastic.co/en/integrations/endpoint integration. +- To install Elastic Defend, refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html. + +#### The following steps should be executed to install assets associated with the Lateral Movement Detection integration: +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Lateral Movement Detection and select the integration to see more details about it. +- Under Settings, click Install Lateral Movement Detection assets and follow the prompts to install the assets. + +#### Anomaly Detection Setup +Before you can enable rules for Lateral Movement Detection, you'll need to enable the corresponding Anomaly Detection jobs. +- Before enabling the Anomaly Detection jobs, confirm that the Pivot Transform asset is installed and actively gathering data in the destination index `ml-rdp-lmd`. +- Go to the Kibana homepage. Under Analytics, click Machine Learning. +- Under Anomaly Detection, click Jobs, and then click "Create job". Select the Data View containing your transformed RDP process data i.e.`ml-rdp-lmd`. +- If the selected Data View contains events that match the query in https://github.com/elastic/integrations/blob/main/packages/lmd/kibana/ml_module/lmd-ml.json configuration file, you will see a card for Lateral Movement Detection under "Use preconfigured jobs". +- Keep the default settings and click "Create jobs" to start the anomaly detection jobs and datafeeds. + +---------------------------------- + *Framework*: MITRE ATT&CK^TM^ * Tactic: diff --git a/docs/detections/prebuilt-rules/rule-details/high-number-of-okta-user-password-reset-or-unlock-attempts.asciidoc b/docs/detections/prebuilt-rules/rule-details/high-number-of-okta-user-password-reset-or-unlock-attempts.asciidoc index ffef8b8ff2..75401d6673 100644 --- a/docs/detections/prebuilt-rules/rule-details/high-number-of-okta-user-password-reset-or-unlock-attempts.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/high-number-of-okta-user-password-reset-or-unlock-attempts.asciidoc @@ -74,6 +74,14 @@ This rule is designed to detect a suspiciously high number of password reset or - Consider a security review of your Okta policies and rules to ensure they follow security best practices. ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/high-number-of-process-terminations.asciidoc b/docs/detections/prebuilt-rules/rule-details/high-number-of-process-terminations.asciidoc index 408aa506f7..5f2e68c362 100644 --- a/docs/detections/prebuilt-rules/rule-details/high-number-of-process-terminations.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/high-number-of-process-terminations.asciidoc @@ -80,6 +80,38 @@ This rule identifies a high number (10) of process terminations via pkill from t - 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 + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/high-variance-in-rdp-session-duration.asciidoc b/docs/detections/prebuilt-rules/rule-details/high-variance-in-rdp-session-duration.asciidoc index 172d7a249c..e8fca50bc0 100644 --- a/docs/detections/prebuilt-rules/rule-details/high-variance-in-rdp-session-duration.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/high-variance-in-rdp-session-duration.asciidoc @@ -40,6 +40,37 @@ A machine learning job has detected unusually high variance of RDP session durat *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- +The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration. + +### Lateral Movement Detection Setup +The Lateral Movement Detection integration detects lateral movement activity by identifying abnormalities in file and Windows RDP events. Anomalies are detected using Elastic's Anomaly Detection feature. + +#### Prerequisite Requirements: +- Fleet is required for Lateral Movement Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html. +- Windows RDP process events collected by the https://docs.elastic.co/en/integrations/endpoint integration. +- To install Elastic Defend, refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html. + +#### The following steps should be executed to install assets associated with the Lateral Movement Detection integration: +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Lateral Movement Detection and select the integration to see more details about it. +- Under Settings, click Install Lateral Movement Detection assets and follow the prompts to install the assets. + +#### Anomaly Detection Setup +Before you can enable rules for Lateral Movement Detection, you'll need to enable the corresponding Anomaly Detection jobs. +- Before enabling the Anomaly Detection jobs, confirm that the Pivot Transform asset is installed and actively gathering data in the destination index `ml-rdp-lmd`. +- Go to the Kibana homepage. Under Analytics, click Machine Learning. +- Under Anomaly Detection, click Jobs, and then click "Create job". Select the Data View containing your transformed RDP process data i.e.`ml-rdp-lmd`. +- If the selected Data View contains events that match the query in https://github.com/elastic/integrations/blob/main/packages/lmd/kibana/ml_module/lmd-ml.json configuration file, you will see a card for Lateral Movement Detection under "Use preconfigured jobs". +- Keep the default settings and click "Create jobs" to start the anomaly detection jobs and datafeeds. + +---------------------------------- + *Framework*: MITRE ATT&CK^TM^ * Tactic: diff --git a/docs/detections/prebuilt-rules/rule-details/hosts-file-modified.asciidoc b/docs/detections/prebuilt-rules/rule-details/hosts-file-modified.asciidoc index f62945fa00..1657ce89e4 100644 --- a/docs/detections/prebuilt-rules/rule-details/hosts-file-modified.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/hosts-file-modified.asciidoc @@ -55,7 +55,7 @@ The hosts file on endpoints is used to control manual IP address to hostname res ### Investigating Hosts File Modified -Operating systems use the hosts file to map a connection between an IP address and domain names before going to domain name servers. Attackers can abuse this mechanism to route traffic to malicious infrastructure or disrupt security that depends on server communications. For example, Russian threat actors modified this file on a domain controller to redirect Duo MFA calls to localhost instead of the Duo server, which prevented the MFA service from contacting its server to validate MFA login. This effectively disabled MFA for active domain accounts because the default policy of Duo for Windows is to "Fail open" if the MFA server is unreachable. This can happen in any MFA implementation and is not exclusive to Duo. Find more details in this [CISA Alert](https://www.cisa.gov/uscert/ncas/alerts/aa22-074a). +Operating systems use the hosts file to map a connection between an IP address and domain names before going to domain name servers. Attackers can abuse this mechanism to route traffic to malicious infrastructure or disrupt security that depends on server communications. For example, Russian threat actors modified this file on a domain controller to redirect Duo MFA calls to localhost instead of the Duo server, which prevented the MFA service from contacting its server to validate MFA login. This effectively disabled MFA for active domain accounts because the default policy of Duo for Windows is to "Fail open" if the MFA server is unreachable. This can happen in any MFA implementation and is not exclusive to Duo. Find more details in this https://www.cisa.gov/uscert/ncas/alerts/aa22-074a. This rule identifies modifications in the hosts file across multiple operating systems using process creation events for Linux and file events in Windows and macOS. @@ -83,6 +83,23 @@ This rule identifies modifications in the hosts file across multiple operating s - 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 + + +[source, markdown] +---------------------------------- + +For Windows systems using Auditbeat, this rule requires adding `C:/Windows/System32/drivers/etc` as an additional path in the 'file_integrity' module of auditbeat.yml. + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/hping-process-activity.asciidoc b/docs/detections/prebuilt-rules/rule-details/hping-process-activity.asciidoc index 12cae0325d..79ca2b63a0 100644 --- a/docs/detections/prebuilt-rules/rule-details/hping-process-activity.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/hping-process-activity.asciidoc @@ -43,6 +43,50 @@ Hping ran on a Linux host. Hping is a FOSS command-line packet analyzer and has *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Auditbeat + +### 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. + +#### 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. +- 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. +- 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. + +### Auditbeat Setup +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + +#### The following steps should be executed in order to add the Auditbeat on a Linux System: +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/iis-http-logging-disabled.asciidoc b/docs/detections/prebuilt-rules/rule-details/iis-http-logging-disabled.asciidoc index cb8fa94895..fe74404126 100644 --- a/docs/detections/prebuilt-rules/rule-details/iis-http-logging-disabled.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/iis-http-logging-disabled.asciidoc @@ -84,6 +84,20 @@ This rule monitors commands that disable IIS logging. - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/imageload-via-windows-update-auto-update-client.asciidoc b/docs/detections/prebuilt-rules/rule-details/imageload-via-windows-update-auto-update-client.asciidoc index c5fc95e46e..3a40358908 100644 --- a/docs/detections/prebuilt-rules/rule-details/imageload-via-windows-update-auto-update-client.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/imageload-via-windows-update-auto-update-client.asciidoc @@ -60,7 +60,7 @@ The Windows Update Auto Update Client (wuauclt.exe) is the component responsible This rule identifies potential abuse for code execution by monitoring for specific process arguments ("/RunHandlerComServer" and "/UpdateDeploymentProvider") and common writable paths where the target DLL can be placed (e.g., "C:\Users\*.dll", "C:\ProgramData\*.dll", etc.). > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. ### Possible investigation steps @@ -104,6 +104,20 @@ This rule identifies potential abuse for code execution by monitoring for specif ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/inbound-connection-to-an-unsecure-elasticsearch-node.asciidoc b/docs/detections/prebuilt-rules/rule-details/inbound-connection-to-an-unsecure-elasticsearch-node.asciidoc index 9cc0bbb3a4..4d3ae1b469 100644 --- a/docs/detections/prebuilt-rules/rule-details/inbound-connection-to-an-unsecure-elasticsearch-node.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/inbound-connection-to-an-unsecure-elasticsearch-node.asciidoc @@ -48,6 +48,14 @@ Identifies Elasticsearch nodes that do not have Transport Layer Security (TLS), ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +This rule requires the addition of port `9200` and `send_all_headers` to the `HTTP` protocol configuration in `packetbeat.yml`. See the References section for additional configuration documentation. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/ingress-transfer-via-windows-bits.asciidoc b/docs/detections/prebuilt-rules/rule-details/ingress-transfer-via-windows-bits.asciidoc index 59efc2d15d..dcc8d11035 100644 --- a/docs/detections/prebuilt-rules/rule-details/ingress-transfer-via-windows-bits.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/ingress-transfer-via-windows-bits.asciidoc @@ -55,7 +55,7 @@ Windows Background Intelligent Transfer Service (BITS) is a technology that allo This rule identifies such abuse by monitoring for file renaming events involving "svchost.exe" and "BIT*.tmp" on Windows systems. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. ### Possible investigation steps @@ -66,11 +66,11 @@ This rule identifies such abuse by monitoring for file renaming events involving - Try to determine the origin of the file. - Inspect network connections initiated by `svchost.exe`. - Inspect `Microsoft-Windows-Bits-Client/Operational` Windows logs, specifically the event ID 59, for unusual events. - - Velociraptor can be used to extract these entries using the [bitsadmin artifact](https://docs.velociraptor.app/exchange/artifacts/pages/bitsadmin/). + - Velociraptor can be used to extract these entries using the https://docs.velociraptor.app/exchange/artifacts/pages/bitsadmin/. - Check the reputation of the remote server involved in the BITS transfer, such as its IP address or domain, using threat intelligence platforms or online reputation services. - Check if the domain is newly registered or unexpected. - Use the identified domain as an indicator of compromise (IoCs) to scope other compromised hosts in the environment. - - [BitsParser](https://github.com/fireeye/BitsParser) can be used to parse BITS database files to extract BITS job information. + - https://github.com/fireeye/BitsParser can be used to parse BITS database files to extract BITS job information. - Examine the details of the dropped file, and whether it was executed. - Investigate other alerts associated with the user/host during the past 48 hours. - Examine the host for derived artifacts that indicate suspicious activities: diff --git a/docs/detections/prebuilt-rules/rule-details/installation-of-security-support-provider.asciidoc b/docs/detections/prebuilt-rules/rule-details/installation-of-security-support-provider.asciidoc index 9ee94d7322..d98cae4066 100644 --- a/docs/detections/prebuilt-rules/rule-details/installation-of-security-support-provider.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/installation-of-security-support-provider.asciidoc @@ -43,6 +43,20 @@ Identifies registry modifications related to the Windows Security Support Provid *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/interactive-logon-by-an-unusual-process.asciidoc b/docs/detections/prebuilt-rules/rule-details/interactive-logon-by-an-unusual-process.asciidoc index b02259fac5..3092b0b6fe 100644 --- a/docs/detections/prebuilt-rules/rule-details/interactive-logon-by-an-unusual-process.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/interactive-logon-by-an-unusual-process.asciidoc @@ -41,6 +41,22 @@ Identifies interactive logon attempt with alternate credentials and by an unusua *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +Audit event 4624 is needed to trigger this rule. + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/interactive-terminal-spawned-via-perl.asciidoc b/docs/detections/prebuilt-rules/rule-details/interactive-terminal-spawned-via-perl.asciidoc index 2027977c59..622ae918bd 100644 --- a/docs/detections/prebuilt-rules/rule-details/interactive-terminal-spawned-via-perl.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/interactive-terminal-spawned-via-perl.asciidoc @@ -41,6 +41,50 @@ Identifies when a terminal (tty) is spawned via Perl. Attackers may upgrade a si *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Auditbeat + +### 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. + +#### 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. +- 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. +- 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. + +### Auditbeat Setup +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + +#### The following steps should be executed in order to add the Auditbeat on a Linux System: +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/interactive-terminal-spawned-via-python.asciidoc b/docs/detections/prebuilt-rules/rule-details/interactive-terminal-spawned-via-python.asciidoc index 96cef32923..2d1aff709c 100644 --- a/docs/detections/prebuilt-rules/rule-details/interactive-terminal-spawned-via-python.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/interactive-terminal-spawned-via-python.asciidoc @@ -40,6 +40,38 @@ Identifies when a terminal (tty) is spawned via Python. Attackers may upgrade a *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/kerberos-cached-credentials-dumping.asciidoc b/docs/detections/prebuilt-rules/rule-details/kerberos-cached-credentials-dumping.asciidoc index 7b302428f1..9b8a0c2416 100644 --- a/docs/detections/prebuilt-rules/rule-details/kerberos-cached-credentials-dumping.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/kerberos-cached-credentials-dumping.asciidoc @@ -41,6 +41,38 @@ Identifies the use of the Kerberos credential cache (kcc) utility to dump locall *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### The following steps should be executed in order to add the Elastic Defend integration on a macOS 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, for MacOS it is recommended to select "Traditional Endpoints". +- 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/kerberos-pre-authentication-disabled-for-user.asciidoc b/docs/detections/prebuilt-rules/rule-details/kerberos-pre-authentication-disabled-for-user.asciidoc index bf8402918a..768355cf1b 100644 --- a/docs/detections/prebuilt-rules/rule-details/kerberos-pre-authentication-disabled-for-user.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/kerberos-pre-authentication-disabled-for-user.asciidoc @@ -57,7 +57,7 @@ Identifies the modification of an account's Kerberos pre-authentication options. ### Investigating Kerberos Pre-authentication Disabled for User -Kerberos pre-authentication is an account protection against offline password cracking. When enabled, a user requesting access to a resource initiates communication with the Domain Controller (DC) by sending an Authentication Server Request (AS-REQ) message with a timestamp that is encrypted with the hash of their password. If and only if the DC is able to successfully decrypt the timestamp with the hash of the user’s password, it will then send an Authentication Server Response (AS-REP) message that contains the Ticket Granting Ticket (TGT) to the user. Part of the AS-REP message is signed with the user’s password. Microsoft's security monitoring [recommendations](https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4738) state that `'Don't Require Preauth' – Enabled` should not be enabled for user accounts because it weakens security for the account’s Kerberos authentication. +Kerberos pre-authentication is an account protection against offline password cracking. When enabled, a user requesting access to a resource initiates communication with the Domain Controller (DC) by sending an Authentication Server Request (AS-REQ) message with a timestamp that is encrypted with the hash of their password. If and only if the DC is able to successfully decrypt the timestamp with the hash of the user’s password, it will then send an Authentication Server Response (AS-REP) message that contains the Ticket Granting Ticket (TGT) to the user. Part of the AS-REP message is signed with the user’s password. Microsoft's security monitoring https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4738 state that `'Don't Require Preauth' – Enabled` should not be enabled for user accounts because it weakens security for the account’s Kerberos authentication. AS-REP roasting is an attack against Kerberos for user accounts that do not require pre-authentication, which means that if the target user has pre-authentication disabled, an attacker can request authentication data for it and get a TGT that can be brute-forced offline, similarly to Kerberoasting. @@ -82,6 +82,28 @@ AS-REP roasting is an attack against Kerberos for user accounts that do not requ - 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 + + +[source, markdown] +---------------------------------- + +The 'Audit User Account Management' 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 > +Account Management > +Audit User Account Management (Success,Failure) +``` + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/kerberos-traffic-from-unusual-process.asciidoc b/docs/detections/prebuilt-rules/rule-details/kerberos-traffic-from-unusual-process.asciidoc index 9590a1cf5e..0f7ed2ecad 100644 --- a/docs/detections/prebuilt-rules/rule-details/kerberos-traffic-from-unusual-process.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/kerberos-traffic-from-unusual-process.asciidoc @@ -53,7 +53,7 @@ Kerberos is the default authentication protocol in Active Directory, designed to Domain-joined hosts usually perform Kerberos traffic using the `lsass.exe` process. This rule detects the occurrence of traffic on the Kerberos port (88) by processes other than `lsass.exe` to detect the unusual request and usage of Kerberos tickets. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps @@ -98,6 +98,20 @@ Domain-joined hosts usually perform Kerberos traffic using the `lsass.exe` proce - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/kernel-driver-load-by-non-root-user.asciidoc b/docs/detections/prebuilt-rules/rule-details/kernel-driver-load-by-non-root-user.asciidoc index f9eefdc849..8fde2e191e 100644 --- a/docs/detections/prebuilt-rules/rule-details/kernel-driver-load-by-non-root-user.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/kernel-driver-load-by-non-root-user.asciidoc @@ -38,6 +38,38 @@ Detects the loading of a Linux kernel module by a non-root user through system c *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +This rule requires data coming in from Auditd Manager. + +### 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" on a Linux 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. + +#### 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 the following additional audit rules are required to be added to the integration: + -- "-a always,exit -F arch=b64 -S finit_module -S init_module -S delete_module -F auid!=-1 -k modules" + -- "-a always,exit -F arch=b32 -S finit_module -S init_module -S delete_module -F auid!=-1 -k modules" + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/kernel-driver-load.asciidoc b/docs/detections/prebuilt-rules/rule-details/kernel-driver-load.asciidoc index 2a36b59775..5b963027e2 100644 --- a/docs/detections/prebuilt-rules/rule-details/kernel-driver-load.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/kernel-driver-load.asciidoc @@ -40,6 +40,34 @@ Detects the loading of a Linux kernel module through system calls. Threat actors *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- +## Setup +This rule requires the use of the `auditd_manager` integration. `Auditd_manager` is a tool designed to simplify and enhance the management of the audit subsystem in Linux systems. It provides a user-friendly interface and automation capabilities for configuring and monitoring system auditing through the auditd daemon. With `auditd_manager`, administrators can easily define audit rules, track system events, and generate comprehensive audit reports, improving overall security and compliance in the system. The following steps should be executed in order to install and deploy `auditd_manager` on a Linux system. + +``` +Kibana --> +Management --> +Integrations --> +Auditd Manager --> +Add Auditd Manager +``` + +`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 to trigger, the following additional audit rules are required to be added to the integration: +``` +-a always,exit -F arch=b64 -S finit_module -S init_module -S delete_module -F auid!=-1 -k modules +-a always,exit -F arch=b32 -S finit_module -S init_module -S delete_module -F auid!=-1 -k modules +``` + +Add the newly installed `auditd manager` to an agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/kernel-load-or-unload-via-kexec-detected.asciidoc b/docs/detections/prebuilt-rules/rule-details/kernel-load-or-unload-via-kexec-detected.asciidoc index 91f47570ee..e3df10fe64 100644 --- a/docs/detections/prebuilt-rules/rule-details/kernel-load-or-unload-via-kexec-detected.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/kernel-load-or-unload-via-kexec-detected.asciidoc @@ -44,6 +44,38 @@ This detection rule identifies the usage of kexec, helping to uncover unauthoriz *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/kernel-module-load-via-insmod.asciidoc b/docs/detections/prebuilt-rules/rule-details/kernel-module-load-via-insmod.asciidoc index d8fee1a3db..62cd47938e 100644 --- a/docs/detections/prebuilt-rules/rule-details/kernel-module-load-via-insmod.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/kernel-module-load-via-insmod.asciidoc @@ -59,8 +59,8 @@ Threat actors can abuse this utility to load rootkits, granting them full contro The detection rule 'Kernel module load via insmod' is designed to identify instances where the insmod binary is used to load a kernel object file (with a .ko extension) on a Linux system. This activity is uncommon and may indicate suspicious or malicious behavior. > **Note**: -> This investigation guide uses the {security-guide}/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. -> This investigation guide uses {security-guide}/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. ### Possible investigation steps @@ -120,6 +120,38 @@ The detection rule 'Kernel module load via insmod' is designed to identify insta - Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. - Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). +---------------------------------- + +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/kernel-module-removal.asciidoc b/docs/detections/prebuilt-rules/rule-details/kernel-module-removal.asciidoc index 0e37cb2928..8d8768e3d0 100644 --- a/docs/detections/prebuilt-rules/rule-details/kernel-module-removal.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/kernel-module-removal.asciidoc @@ -42,6 +42,38 @@ Kernel modules are pieces of code that can be loaded and unloaded into the kerne *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/keychain-password-retrieval-via-command-line.asciidoc b/docs/detections/prebuilt-rules/rule-details/keychain-password-retrieval-via-command-line.asciidoc index 71af9ed37b..ed8b9182b6 100644 --- a/docs/detections/prebuilt-rules/rule-details/keychain-password-retrieval-via-command-line.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/keychain-password-retrieval-via-command-line.asciidoc @@ -43,6 +43,38 @@ Adversaries may collect keychain storage data from a system to in order to acqui *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### The following steps should be executed in order to add the Elastic Defend integration on a macOS 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, for MacOS it is recommended to select "Traditional Endpoints". +- 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/krbtgt-delegation-backdoor.asciidoc b/docs/detections/prebuilt-rules/rule-details/krbtgt-delegation-backdoor.asciidoc index e45919fc07..dc7c8853cf 100644 --- a/docs/detections/prebuilt-rules/rule-details/krbtgt-delegation-backdoor.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/krbtgt-delegation-backdoor.asciidoc @@ -44,6 +44,28 @@ Identifies the modification of the msDS-AllowedToDelegateTo attribute to KRBTGT. *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +The 'Audit User Account Management' 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 > +Account Management > +Audit User Account Management (Success,Failure) +``` + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/kubernetes-anonymous-request-authorized.asciidoc b/docs/detections/prebuilt-rules/rule-details/kubernetes-anonymous-request-authorized.asciidoc index 13f8e18c3f..2b8f9903bb 100644 --- a/docs/detections/prebuilt-rules/rule-details/kubernetes-anonymous-request-authorized.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/kubernetes-anonymous-request-authorized.asciidoc @@ -47,6 +47,14 @@ This rule detects when an unauthenticated user request is authorized within the ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/kubernetes-container-created-with-excessive-linux-capabilities.asciidoc b/docs/detections/prebuilt-rules/rule-details/kubernetes-container-created-with-excessive-linux-capabilities.asciidoc index 8bd366e589..d812288c6e 100644 --- a/docs/detections/prebuilt-rules/rule-details/kubernetes-container-created-with-excessive-linux-capabilities.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/kubernetes-container-created-with-excessive-linux-capabilities.asciidoc @@ -68,6 +68,14 @@ SYSLOG - Perform privileged syslog(2) operations. - While these capabilities are not included by default in containers, some legitimate images may need to add them. This rule leaves space for the exception of trusted container images. To add an exception, add the trusted container image name to the query field, kubernetes.audit.requestObject.spec.containers.image. ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/kubernetes-denied-service-account-request.asciidoc b/docs/detections/prebuilt-rules/rule-details/kubernetes-denied-service-account-request.asciidoc index 90e1c1675c..ad84c0da2c 100644 --- a/docs/detections/prebuilt-rules/rule-details/kubernetes-denied-service-account-request.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/kubernetes-denied-service-account-request.asciidoc @@ -46,6 +46,14 @@ This rule detects when a service account makes an unauthorized request for resou ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/kubernetes-exposed-service-created-with-type-nodeport.asciidoc b/docs/detections/prebuilt-rules/rule-details/kubernetes-exposed-service-created-with-type-nodeport.asciidoc index 95de5ec3f2..1a9e0309a6 100644 --- a/docs/detections/prebuilt-rules/rule-details/kubernetes-exposed-service-created-with-type-nodeport.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/kubernetes-exposed-service-created-with-type-nodeport.asciidoc @@ -48,6 +48,14 @@ This rule detects an attempt to create or modify a service as type NodePort. The ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/kubernetes-pod-created-with-a-sensitive-hostpath-volume.asciidoc b/docs/detections/prebuilt-rules/rule-details/kubernetes-pod-created-with-a-sensitive-hostpath-volume.asciidoc index 1efcc355ec..5a3a4643a6 100644 --- a/docs/detections/prebuilt-rules/rule-details/kubernetes-pod-created-with-a-sensitive-hostpath-volume.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/kubernetes-pod-created-with-a-sensitive-hostpath-volume.asciidoc @@ -47,6 +47,14 @@ This rule detects when a pod is created with a sensitive volume of type hostPath ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/kubernetes-pod-created-with-hostipc.asciidoc b/docs/detections/prebuilt-rules/rule-details/kubernetes-pod-created-with-hostipc.asciidoc index e4fa9dd324..3e45527107 100644 --- a/docs/detections/prebuilt-rules/rule-details/kubernetes-pod-created-with-hostipc.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/kubernetes-pod-created-with-hostipc.asciidoc @@ -48,6 +48,14 @@ This rule detects an attempt to create or modify a pod using the host IPC namesp ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/kubernetes-pod-created-with-hostnetwork.asciidoc b/docs/detections/prebuilt-rules/rule-details/kubernetes-pod-created-with-hostnetwork.asciidoc index bdcdeb3847..2595ff84de 100644 --- a/docs/detections/prebuilt-rules/rule-details/kubernetes-pod-created-with-hostnetwork.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/kubernetes-pod-created-with-hostnetwork.asciidoc @@ -48,6 +48,14 @@ This rules detects an attempt to create or modify a pod attached to the host net ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/kubernetes-pod-created-with-hostpid.asciidoc b/docs/detections/prebuilt-rules/rule-details/kubernetes-pod-created-with-hostpid.asciidoc index 17ed5188bc..8788dc230a 100644 --- a/docs/detections/prebuilt-rules/rule-details/kubernetes-pod-created-with-hostpid.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/kubernetes-pod-created-with-hostpid.asciidoc @@ -48,6 +48,14 @@ This rule detects an attempt to create or modify a pod attached to the host PID ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/kubernetes-privileged-pod-created.asciidoc b/docs/detections/prebuilt-rules/rule-details/kubernetes-privileged-pod-created.asciidoc index 5d0ccb441c..c4234d722f 100644 --- a/docs/detections/prebuilt-rules/rule-details/kubernetes-privileged-pod-created.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/kubernetes-privileged-pod-created.asciidoc @@ -47,6 +47,14 @@ This rule detects when a user creates a pod/container running in privileged mode ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/kubernetes-suspicious-assignment-of-controller-service-account.asciidoc b/docs/detections/prebuilt-rules/rule-details/kubernetes-suspicious-assignment-of-controller-service-account.asciidoc index 831cd8aaa7..67ff145230 100644 --- a/docs/detections/prebuilt-rules/rule-details/kubernetes-suspicious-assignment-of-controller-service-account.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/kubernetes-suspicious-assignment-of-controller-service-account.asciidoc @@ -46,6 +46,14 @@ This rule detects a request to attach a controller service account to an existin ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/kubernetes-suspicious-self-subject-review.asciidoc b/docs/detections/prebuilt-rules/rule-details/kubernetes-suspicious-self-subject-review.asciidoc index 45d7781a1d..e70a63a682 100644 --- a/docs/detections/prebuilt-rules/rule-details/kubernetes-suspicious-self-subject-review.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/kubernetes-suspicious-self-subject-review.asciidoc @@ -47,6 +47,14 @@ This rule detects when a service account or node attempts to enumerate their own ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/kubernetes-user-exec-into-pod.asciidoc b/docs/detections/prebuilt-rules/rule-details/kubernetes-user-exec-into-pod.asciidoc index 0d019bf1d7..9a71d9b937 100644 --- a/docs/detections/prebuilt-rules/rule-details/kubernetes-user-exec-into-pod.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/kubernetes-user-exec-into-pod.asciidoc @@ -46,6 +46,14 @@ This rule detects a user attempt to establish a shell session into a pod using t ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/lateral-movement-via-startup-folder.asciidoc b/docs/detections/prebuilt-rules/rule-details/lateral-movement-via-startup-folder.asciidoc index de417e0fba..7606feb081 100644 --- a/docs/detections/prebuilt-rules/rule-details/lateral-movement-via-startup-folder.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/lateral-movement-via-startup-folder.asciidoc @@ -44,6 +44,20 @@ Identifies suspicious file creations in the startup folder of a remote system. A *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/launch-agent-creation-or-modification-and-immediate-loading.asciidoc b/docs/detections/prebuilt-rules/rule-details/launch-agent-creation-or-modification-and-immediate-loading.asciidoc index f01e5fe8ba..8b5a469fab 100644 --- a/docs/detections/prebuilt-rules/rule-details/launch-agent-creation-or-modification-and-immediate-loading.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/launch-agent-creation-or-modification-and-immediate-loading.asciidoc @@ -40,6 +40,38 @@ An adversary can establish persistence by installing a new launch agent that exe *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### The following steps should be executed in order to add the Elastic Defend integration on a macOS 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, for MacOS it is recommended to select "Traditional Endpoints". +- 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/launchdaemon-creation-or-modification-and-immediate-loading.asciidoc b/docs/detections/prebuilt-rules/rule-details/launchdaemon-creation-or-modification-and-immediate-loading.asciidoc index 931f8c83bd..0b9cc5d365 100644 --- a/docs/detections/prebuilt-rules/rule-details/launchdaemon-creation-or-modification-and-immediate-loading.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/launchdaemon-creation-or-modification-and-immediate-loading.asciidoc @@ -40,6 +40,38 @@ Indicates the creation or modification of a launch daemon, which adversaries may *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### The following steps should be executed in order to add the Elastic Defend integration on a macOS 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, for MacOS it is recommended to select "Traditional Endpoints". +- 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/linux-group-creation.asciidoc b/docs/detections/prebuilt-rules/rule-details/linux-group-creation.asciidoc index c29e4d1aab..53c98ca49f 100644 --- a/docs/detections/prebuilt-rules/rule-details/linux-group-creation.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/linux-group-creation.asciidoc @@ -54,8 +54,8 @@ Attackers may create new groups to maintain access to victim systems or escalate This rule identifies the usages of `groupadd` and `addgroup` to create new groups. > **Note**: -> This investigation guide uses the {security-guide}/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. -> This investigation guide uses {security-guide}/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. #### Possible investigation steps @@ -91,6 +91,33 @@ This rule identifies the usages of `groupadd` and `addgroup` to create new group - Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). +---------------------------------- + +==== Setup + + +[source, markdown] +---------------------------------- + +This rule requires data coming in from Filebeat. + +### Filebeat Setup +Filebeat is a lightweight shipper for forwarding and centralizing log data. Installed as an agent on your servers, Filebeat monitors the log files or locations that you specify, collects log events, and forwards them either to Elasticsearch or Logstash for indexing. + +#### The following steps should be executed in order to add the Filebeat on a Linux System: +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/filebeat/current/setup-repositories.html. +- To run Filebeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/running-on-docker.html. +- To run Filebeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/running-on-kubernetes.html. +- For quick start information for Filebeat refer to the https://www.elastic.co/guide/en/beats/filebeat/8.11/filebeat-installation-configuration.html. +- For complete “Setup and Run Filebeat” information refer to the https://www.elastic.co/guide/en/beats/filebeat/current/setting-up-and-running.html. + +#### Rule Specific Setup Note +- This rule requires the “Filebeat System Module” to be enabled. +- The system module collects and parses logs created by the system logging service of common Unix/Linux based distributions. +- To run the system module of Filebeat on Linux follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-system.html. + + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/linux-init-pid-1-secret-dump-via-gdb.asciidoc b/docs/detections/prebuilt-rules/rule-details/linux-init-pid-1-secret-dump-via-gdb.asciidoc index 0f08b7f018..b9de1999fb 100644 --- a/docs/detections/prebuilt-rules/rule-details/linux-init-pid-1-secret-dump-via-gdb.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/linux-init-pid-1-secret-dump-via-gdb.asciidoc @@ -41,6 +41,38 @@ This rule monitors for the potential memory dump of the init process (PID 1) thr *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/linux-restricted-shell-breakout-via-linux-binary-s.asciidoc b/docs/detections/prebuilt-rules/rule-details/linux-restricted-shell-breakout-via-linux-binary-s.asciidoc index 21bb4c5e5f..389a40138b 100644 --- a/docs/detections/prebuilt-rules/rule-details/linux-restricted-shell-breakout-via-linux-binary-s.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/linux-restricted-shell-breakout-via-linux-binary-s.asciidoc @@ -116,6 +116,47 @@ Initiate the incident response process based on the outcome of the triage. - 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 + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + +Session View uses process data collected by the Elastic Defend integration, but this data is not always collected by default. Session View is available on enterprise subscription for versions 8.3 and above. +#### To confirm that Session View data is enabled: +- Go to “Manage → Policies”, and edit one or more of your Elastic Defend integration policies. +- Select the” Policy settings” tab, then scroll down to the “Linux event collection” section near the bottom. +- Check the box for “Process events”, and turn on the “Include session data” toggle. +- If you want to include file and network alerts in Session View, check the boxes for “Network and File events”. +- If you want to enable terminal output capture, turn on the “Capture terminal output” toggle. +For more information about the additional fields collected when this setting is enabled and the usage of Session View for Analysis refer to the https://www.elastic.co/guide/en/security/current/session-view.html. + + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/linux-user-account-creation.asciidoc b/docs/detections/prebuilt-rules/rule-details/linux-user-account-creation.asciidoc index e3faf3076b..dc4896f754 100644 --- a/docs/detections/prebuilt-rules/rule-details/linux-user-account-creation.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/linux-user-account-creation.asciidoc @@ -54,8 +54,8 @@ Attackers may create new accounts (both local and domain) to maintain access to This rule identifies the usage of `useradd` and `adduser` to create new accounts. > **Note**: -> This investigation guide uses the {security-guide}/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. -> This investigation guide uses {security-guide}/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. #### Possible investigation steps @@ -90,6 +90,33 @@ This rule identifies the usage of `useradd` and `adduser` to create new accounts - 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 + + +[source, markdown] +---------------------------------- + +This rule requires data coming in from Filebeat. + +### Filebeat Setup +Filebeat is a lightweight shipper for forwarding and centralizing log data. Installed as an agent on your servers, Filebeat monitors the log files or locations that you specify, collects log events, and forwards them either to Elasticsearch or Logstash for indexing. + +#### The following steps should be executed in order to add the Filebeat on a Linux System: +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/filebeat/current/setup-repositories.html. +- To run Filebeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/running-on-docker.html. +- To run Filebeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/running-on-kubernetes.html. +- For quick start information for Filebeat refer to the https://www.elastic.co/guide/en/beats/filebeat/8.11/filebeat-installation-configuration.html. +- For complete “Setup and Run Filebeat” information refer to the https://www.elastic.co/guide/en/beats/filebeat/current/setting-up-and-running.html. + +#### Rule Specific Setup Note +- This rule requires the “Filebeat System Module” to be enabled. +- The system module collects and parses logs created by the system logging service of common Unix/Linux based distributions. +- To run the system module of Filebeat on Linux follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-system.html. + + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/linux-user-added-to-privileged-group.asciidoc b/docs/detections/prebuilt-rules/rule-details/linux-user-added-to-privileged-group.asciidoc index 8bd1b4d32c..217cd31424 100644 --- a/docs/detections/prebuilt-rules/rule-details/linux-user-added-to-privileged-group.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/linux-user-added-to-privileged-group.asciidoc @@ -57,8 +57,8 @@ Attackers may add users to a privileged group in order to escalate privileges or This rule identifies the usages of `usermod`, `adduser` and `gpasswd` to assign user accounts to a privileged group. > **Note**: -> This investigation guide uses the {security-guide}/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. -> This investigation guide uses {security-guide}/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. #### Possible investigation steps @@ -93,6 +93,38 @@ This rule identifies the usages of `usermod`, `adduser` and `gpasswd` to assign - 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 + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/lsass-memory-dump-creation.asciidoc b/docs/detections/prebuilt-rules/rule-details/lsass-memory-dump-creation.asciidoc index 6e0692172d..bd840e063b 100644 --- a/docs/detections/prebuilt-rules/rule-details/lsass-memory-dump-creation.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/lsass-memory-dump-creation.asciidoc @@ -60,7 +60,7 @@ Local Security Authority Server Service (LSASS) is a process in Microsoft Window This rule looks for the creation of memory dump files with file names compatible with credential dumping tools or that start with `lsass`. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps @@ -103,6 +103,20 @@ This rule looks for the creation of memory dump files with file names compatible - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/lsass-memory-dump-handle-access.asciidoc b/docs/detections/prebuilt-rules/rule-details/lsass-memory-dump-handle-access.asciidoc index efd15d1093..6eda89feb1 100644 --- a/docs/detections/prebuilt-rules/rule-details/lsass-memory-dump-handle-access.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/lsass-memory-dump-handle-access.asciidoc @@ -58,10 +58,10 @@ Identifies handle requests for the Local Security Authority Subsystem Service (L Local Security Authority Server Service (LSASS) is a process in Microsoft Windows operating systems that is responsible for enforcing security policy on the system. It verifies users logging on to a Windows computer or server, handles password changes, and creates access tokens. -Adversaries may attempt to access credential material stored in LSASS process memory. After a user logs on, the system generates and stores a variety of credential materials in LSASS process memory. This is meant to facilitate single sign-on (SSO) ensuring a user isn’t prompted each time resource access is requested. These credential materials can be harvested by an adversary using administrative user or SYSTEM privileges to conduct lateral movement using [alternate authentication material](https://attack.mitre.org/techniques/T1550/). +Adversaries may attempt to access credential material stored in LSASS process memory. After a user logs on, the system generates and stores a variety of credential materials in LSASS process memory. This is meant to facilitate single sign-on (SSO) ensuring a user isn’t prompted each time resource access is requested. These credential materials can be harvested by an adversary using administrative user or SYSTEM privileges to conduct lateral movement using https://attack.mitre.org/techniques/T1550/. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps @@ -105,6 +105,37 @@ Adversaries may attempt to access credential material stored in LSASS process me - 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 + + +[source, markdown] +---------------------------------- + +Ensure advanced audit policies for Windows are enabled, specifically: +Object Access policies https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4656 (Handle to an Object was Requested) + +``` +Computer Configuration > +Policies > +Windows Settings > +Security Settings > +Advanced Audit Policies Configuration > +System Audit Policies > +Object Access > +Audit File System (Success,Failure) +Audit Handle Manipulation (Success,Failure) +``` + +Also, this event generates only if the object’s https://docs.microsoft.com/en-us/windows/win32/secauthz/access-control-lists has the required access control entry (ACE) to handle the use of specific access rights. + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/lsass-process-access-via-windows-api.asciidoc b/docs/detections/prebuilt-rules/rule-details/lsass-process-access-via-windows-api.asciidoc index 2eb809ef08..1c004c4675 100644 --- a/docs/detections/prebuilt-rules/rule-details/lsass-process-access-via-windows-api.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/lsass-process-access-via-windows-api.asciidoc @@ -55,7 +55,7 @@ The Local Security Authority Subsystem Service (LSASS) is a critical Windows com This rule identifies attempts to access LSASS by monitoring for specific API calls (OpenProcess, OpenThread) targeting the "lsass.exe" process. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. ### Possible investigation steps @@ -65,7 +65,7 @@ This rule identifies attempts to access LSASS by monitoring for specific API cal - Determine the first time the process executable was seen in the environment and if this behavior happened in the past. - Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations. - Investigate any abnormal behavior by the subject process, such as network connections, DLLs loaded, registry or file modifications, and any spawned child processes. -- Assess the access rights (`process.Ext.api.parameters.desired_access`field) requested by the process. This [Microsoft documentation](https://learn.microsoft.com/en-us/windows/win32/procthread/process-security-and-access-rights) may be useful to help the interpretation. +- Assess the access rights (`process.Ext.api.parameters.desired_access`field) requested by the process. This https://learn.microsoft.com/en-us/windows/win32/procthread/process-security-and-access-rights may be useful to help the interpretation. - If there are traces of LSASS memory being successfully dumped, investigate potentially compromised accounts. Analysts can do this by searching for login events (e.g., 4624) to the target host. - Examine the host for derived artifacts that indicate suspicious activities: - Analyze the executables of the processes using a private sandboxed analysis system. diff --git a/docs/detections/prebuilt-rules/rule-details/machine-learning-detected-a-dns-request-predicted-to-be-a-dga-domain.asciidoc b/docs/detections/prebuilt-rules/rule-details/machine-learning-detected-a-dns-request-predicted-to-be-a-dga-domain.asciidoc index e048c7687f..73f05136b9 100644 --- a/docs/detections/prebuilt-rules/rule-details/machine-learning-detected-a-dns-request-predicted-to-be-a-dga-domain.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/machine-learning-detected-a-dns-request-predicted-to-be-a-dga-domain.asciidoc @@ -45,6 +45,57 @@ A supervised machine learning model has identified a DNS question name that is p *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- +The rule requires the Domain Generation Algorithm (DGA) Detection integration assets to be installed, as well as DNS events collected by integrations such as Elastic Defend, Network Packet Capture, or Packetbeat. + +### DGA Detection Setup +The DGA Detection integration consists of an ML-based framework to detect DGA activity in DNS events. + +#### Prerequisite Requirements: +- Fleet is required for DGA Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html. +- DNS events collected by the https://docs.elastic.co/en/integrations/endpoint, https://docs.elastic.co/integrations/network_traffic integration, or https://www.elastic.co/guide/en/beats/packetbeat/current/packetbeat-overview.html. +- To install Elastic Defend, refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html. +- To add the Network Packet Capture integration to an Elastic Agent policy, refer to https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html guide. +- To set up and run Packetbeat, follow https://www.elastic.co/guide/en/beats/packetbeat/current/setting-up-and-running.html guide. + +#### The following steps should be executed to install assets associated with the DGA Detection integration: +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Domain Generation Algorithm Detection and select the integration to see more details about it. +- Under Settings, click Install Domain Generation Algorithm Detection assets and follow the prompts to install the assets. + +#### Ingest Pipeline Setup +Before you can enable this rule, you'll need to enrich DNS events with predictions from the Supervised DGA Detection model. This is done via the ingest pipeline named `-ml_dga_ingest_pipeline` installed with the DGA Detection package. +- If using an Elastic Beat such as Packetbeat, add the DGA ingest pipeline to it by adding a simple configuration https://www.elastic.co/guide/en/elasticsearch/reference/current/ingest.html#pipelines-for-beats to `packetbeat.yml`. +- If adding the DGA ingest pipeline to an existing pipeline, use a https://www.elastic.co/guide/en/elasticsearch/reference/current/pipeline-processor.html. + +#### Adding Custom Mappings +- Go to the Kibana homepage. Under Management, click Stack Management. +- Under Data click Index Management and navigate to the Component Templates tab. +- Templates that can be edited to add custom components will be marked with a @custom suffix. Edit the @custom component template corresponding to the beat/integration you added the DGA ingest pipeline to, by pasting the following JSON blob in the "Load JSON" flyout: +``` +{ + "properties": { + "ml_is_dga": { + "properties": { + "malicious_prediction": { + "type": "long" + }, + "malicious_probability": { + "type": "float" + } + } + } + } +} +``` + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/machine-learning-detected-a-dns-request-with-a-high-dga-probability-score.asciidoc b/docs/detections/prebuilt-rules/rule-details/machine-learning-detected-a-dns-request-with-a-high-dga-probability-score.asciidoc index f5381b9946..616e58d1ec 100644 --- a/docs/detections/prebuilt-rules/rule-details/machine-learning-detected-a-dns-request-with-a-high-dga-probability-score.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/machine-learning-detected-a-dns-request-with-a-high-dga-probability-score.asciidoc @@ -45,6 +45,57 @@ A supervised machine learning model has identified a DNS question name with a hi *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- +The rule requires the Domain Generation Algorithm (DGA) Detection integration assets to be installed, as well as DNS events collected by integrations such as Elastic Defend, Network Packet Capture, or Packetbeat. + +### DGA Detection Setup +The DGA Detection integration consists of an ML-based framework to detect DGA activity in DNS events. + +#### Prerequisite Requirements: +- Fleet is required for DGA Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html. +- DNS events collected by the https://docs.elastic.co/en/integrations/endpoint, https://docs.elastic.co/integrations/network_traffic integration, or https://www.elastic.co/guide/en/beats/packetbeat/current/packetbeat-overview.html. +- To install Elastic Defend, refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html. +- To add the Network Packet Capture integration to an Elastic Agent policy, refer to https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html guide. +- To set up and run Packetbeat, follow https://www.elastic.co/guide/en/beats/packetbeat/current/setting-up-and-running.html guide. + +#### The following steps should be executed to install assets associated with the DGA Detection integration: +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Domain Generation Algorithm Detection and select the integration to see more details about it. +- Under Settings, click Install Domain Generation Algorithm Detection assets and follow the prompts to install the assets. + +#### Ingest Pipeline Setup +Before you can enable this rule, you'll need to enrich DNS events with predictions from the Supervised DGA Detection model. This is done via the ingest pipeline named `-ml_dga_ingest_pipeline` installed with the DGA Detection package. +- If using an Elastic Beat such as Packetbeat, add the DGA ingest pipeline to it by adding a simple configuration https://www.elastic.co/guide/en/elasticsearch/reference/current/ingest.html#pipelines-for-beats to `packetbeat.yml`. +- If adding the DGA ingest pipeline to an existing pipeline, use a https://www.elastic.co/guide/en/elasticsearch/reference/current/pipeline-processor.html. + +#### Adding Custom Mappings +- Go to the Kibana homepage. Under Management, click Stack Management. +- Under Data click Index Management and navigate to the Component Templates tab. +- Templates that can be edited to add custom components will be marked with a @custom suffix. Edit the @custom component template corresponding to the beat/integration you added the DGA ingest pipeline to, by pasting the following JSON blob in the "Load JSON" flyout: +``` +{ + "properties": { + "ml_is_dga": { + "properties": { + "malicious_prediction": { + "type": "long" + }, + "malicious_probability": { + "type": "float" + } + } + } + } +} +``` + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/machine-learning-detected-a-suspicious-windows-event-predicted-to-be-malicious-activity.asciidoc b/docs/detections/prebuilt-rules/rule-details/machine-learning-detected-a-suspicious-windows-event-predicted-to-be-malicious-activity.asciidoc index 047ef8b942..be9edad675 100644 --- a/docs/detections/prebuilt-rules/rule-details/machine-learning-detected-a-suspicious-windows-event-predicted-to-be-malicious-activity.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/machine-learning-detected-a-suspicious-windows-event-predicted-to-be-malicious-activity.asciidoc @@ -45,6 +45,59 @@ A supervised machine learning model (ProblemChild) has identified a suspicious W *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- +The rule requires the Living off the Land (LotL) Attack Detection integration assets to be installed, as well as Windows process events collected by integrations such as Elastic Defend or Winlogbeat. + +### LotL Attack Detection Setup +The LotL Attack Detection integration detects living-off-the-land activity in Windows process events. + +#### Prerequisite Requirements: +- Fleet is required for LotL Attack Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html. +- Windows process events collected by the https://docs.elastic.co/en/integrations/endpoint integration or Winlogbeat(https://www.elastic.co/guide/en/beats/winlogbeat/current/_winlogbeat_overview.html). +- To install Elastic Defend, refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html. +- To set up and run Winlogbeat, follow https://www.elastic.co/guide/en/beats/winlogbeat/current/winlogbeat-installation-configuration.html guide. + +#### The following steps should be executed to install assets associated with the LotL Attack Detection integration: +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Living off the Land Attack Detection and select the integration to see more details about it. +- Under Settings, click Install Living off the Land Attack Detection assets and follow the prompts to install the assets. + +#### Ingest Pipeline Setup +Before you can enable this rule, you'll need to enrich Windows process events with predictions from the Supervised LotL Attack Detection model. This is done via the ingest pipeline named `-problem_child_ingest_pipeline` installed with the LotL Attack Detection package. +- If using an Elastic Beat such as Winlogbeat, add the LotL ingest pipeline to it by adding a simple configuration https://www.elastic.co/guide/en/elasticsearch/reference/current/ingest.html#pipelines-for-beats to `winlogbeat.yml`. +- If adding the LotL ingest pipeline to an existing pipeline, use a https://www.elastic.co/guide/en/elasticsearch/reference/current/pipeline-processor.html. + +#### Adding Custom Mappings +- Go to the Kibana homepage. Under Management, click Stack Management. +- Under Data click Index Management and navigate to the Component Templates tab. +- Templates that can be edited to add custom components will be marked with a @custom suffix. Edit the @custom component template corresponding to the beat/integration you added the LotL ingest pipeline to, by pasting the following JSON blob in the "Load JSON" flyout: +``` +{ + "properties": { + "problemchild": { + "properties": { + "prediction": { + "type": "long" + }, + "prediction_probability": { + "type": "float" + } + } + }, + "blocklist_label": { + "type": "long" + } + } +} +``` + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/machine-learning-detected-a-suspicious-windows-event-with-a-high-malicious-probability-score.asciidoc b/docs/detections/prebuilt-rules/rule-details/machine-learning-detected-a-suspicious-windows-event-with-a-high-malicious-probability-score.asciidoc index 69c199a411..68286df487 100644 --- a/docs/detections/prebuilt-rules/rule-details/machine-learning-detected-a-suspicious-windows-event-with-a-high-malicious-probability-score.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/machine-learning-detected-a-suspicious-windows-event-with-a-high-malicious-probability-score.asciidoc @@ -45,6 +45,59 @@ A supervised machine learning model (ProblemChild) has identified a suspicious W *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- +The rule requires the Living off the Land (LotL) Attack Detection integration assets to be installed, as well as Windows process events collected by integrations such as Elastic Defend or Winlogbeat. + +### LotL Attack Detection Setup +The LotL Attack Detection integration detects living-off-the-land activity in Windows process events. + +#### Prerequisite Requirements: +- Fleet is required for LotL Attack Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html. +- Windows process events collected by the https://docs.elastic.co/en/integrations/endpoint integration or Winlogbeat(https://www.elastic.co/guide/en/beats/winlogbeat/current/_winlogbeat_overview.html). +- To install Elastic Defend, refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html. +- To set up and run Winlogbeat, follow https://www.elastic.co/guide/en/beats/winlogbeat/current/winlogbeat-installation-configuration.html guide. + +#### The following steps should be executed to install assets associated with the LotL Attack Detection integration: +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Living off the Land Attack Detection and select the integration to see more details about it. +- Under Settings, click Install Living off the Land Attack Detection assets and follow the prompts to install the assets. + +#### Ingest Pipeline Setup +Before you can enable this rule, you'll need to enrich Windows process events with predictions from the Supervised LotL Attack Detection model. This is done via the ingest pipeline named `-problem_child_ingest_pipeline` installed with the LotL Attack Detection package. +- If using an Elastic Beat such as Winlogbeat, add the LotL ingest pipeline to it by adding a simple configuration https://www.elastic.co/guide/en/elasticsearch/reference/current/ingest.html#pipelines-for-beats to `winlogbeat.yml`. +- If adding the LotL ingest pipeline to an existing pipeline, use a https://www.elastic.co/guide/en/elasticsearch/reference/current/pipeline-processor.html. + +#### Adding Custom Mappings +- Go to the Kibana homepage. Under Management, click Stack Management. +- Under Data click Index Management and navigate to the Component Templates tab. +- Templates that can be edited to add custom components will be marked with a @custom suffix. Edit the @custom component template corresponding to the beat/integration you added the LotL ingest pipeline to, by pasting the following JSON blob in the "Load JSON" flyout: +``` +{ + "properties": { + "problemchild": { + "properties": { + "prediction": { + "type": "long" + }, + "prediction_probability": { + "type": "float" + } + } + }, + "blocklist_label": { + "type": "long" + } + } +} +``` + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/machine-learning-detected-dga-activity-using-a-known-sunburst-dns-domain.asciidoc b/docs/detections/prebuilt-rules/rule-details/machine-learning-detected-dga-activity-using-a-known-sunburst-dns-domain.asciidoc index e71ea280a2..6c5fe38bb9 100644 --- a/docs/detections/prebuilt-rules/rule-details/machine-learning-detected-dga-activity-using-a-known-sunburst-dns-domain.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/machine-learning-detected-dga-activity-using-a-known-sunburst-dns-domain.asciidoc @@ -45,6 +45,57 @@ A supervised machine learning model has identified a DNS question name that used *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- +The rule requires the Domain Generation Algorithm (DGA) Detection integration assets to be installed, as well as DNS events collected by integrations such as Elastic Defend, Network Packet Capture, or Packetbeat. + +### DGA Detection Setup +The DGA Detection integration consists of an ML-based framework to detect DGA activity in DNS events. + +#### Prerequisite Requirements: +- Fleet is required for DGA Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html. +- DNS events collected by the https://docs.elastic.co/en/integrations/endpoint, https://docs.elastic.co/integrations/network_traffic integration, or https://www.elastic.co/guide/en/beats/packetbeat/current/packetbeat-overview.html. +- To install Elastic Defend, refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html. +- To add the Network Packet Capture integration to an Elastic Agent policy, refer to https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html guide. +- To set up and run Packetbeat, follow https://www.elastic.co/guide/en/beats/packetbeat/current/setting-up-and-running.html guide. + +#### The following steps should be executed to install assets associated with the DGA Detection integration: +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Domain Generation Algorithm Detection and select the integration to see more details about it. +- Under Settings, click Install Domain Generation Algorithm Detection assets and follow the prompts to install the assets. + +#### Ingest Pipeline Setup +Before you can enable this rule, you'll need to enrich DNS events with predictions from the Supervised DGA Detection model. This is done via the ingest pipeline named `-ml_dga_ingest_pipeline` installed with the DGA Detection package. +- If using an Elastic Beat such as Packetbeat, add the DGA ingest pipeline to it by adding a simple configuration https://www.elastic.co/guide/en/elasticsearch/reference/current/ingest.html#pipelines-for-beats to `packetbeat.yml`. +- If adding the DGA ingest pipeline to an existing pipeline, use a https://www.elastic.co/guide/en/elasticsearch/reference/current/pipeline-processor.html. + +#### Adding Custom Mappings +- Go to the Kibana homepage. Under Management, click Stack Management. +- Under Data click Index Management and navigate to the Component Templates tab. +- Templates that can be edited to add custom components will be marked with a @custom suffix. Edit the @custom component template corresponding to the beat/integration you added the DGA ingest pipeline to, by pasting the following JSON blob in the "Load JSON" flyout: +``` +{ + "properties": { + "ml_is_dga": { + "properties": { + "malicious_prediction": { + "type": "long" + }, + "malicious_probability": { + "type": "float" + } + } + } + } +} +``` + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/macos-installer-package-spawns-network-event.asciidoc b/docs/detections/prebuilt-rules/rule-details/macos-installer-package-spawns-network-event.asciidoc index 772c59d1b1..61aac58941 100644 --- a/docs/detections/prebuilt-rules/rule-details/macos-installer-package-spawns-network-event.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/macos-installer-package-spawns-network-event.asciidoc @@ -43,6 +43,38 @@ Detects the execution of a MacOS installer package with an abnormal child proces *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### The following steps should be executed in order to add the Elastic Defend integration on a macOS 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, for MacOS it is recommended to select "Traditional Endpoints". +- 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/masquerading-space-after-filename.asciidoc b/docs/detections/prebuilt-rules/rule-details/masquerading-space-after-filename.asciidoc index 443cfa9644..fe2d130666 100644 --- a/docs/detections/prebuilt-rules/rule-details/masquerading-space-after-filename.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/masquerading-space-after-filename.asciidoc @@ -42,6 +42,20 @@ This rules identifies a process created from an executable with a space appended *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/mfa-deactivation-with-no-re-activation-for-okta-user-account.asciidoc b/docs/detections/prebuilt-rules/rule-details/mfa-deactivation-with-no-re-activation-for-okta-user-account.asciidoc index 592a70afdb..bd9c9fefb6 100644 --- a/docs/detections/prebuilt-rules/rule-details/mfa-deactivation-with-no-re-activation-for-okta-user-account.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/mfa-deactivation-with-no-re-activation-for-okta-user-account.asciidoc @@ -79,6 +79,15 @@ This rule fires when an Okta user account has MFA deactivated and no subsequent ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/mfa-disabled-for-google-workspace-organization.asciidoc b/docs/detections/prebuilt-rules/rule-details/mfa-disabled-for-google-workspace-organization.asciidoc index 484eced8d0..34a920a5a5 100644 --- a/docs/detections/prebuilt-rules/rule-details/mfa-disabled-for-google-workspace-organization.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/mfa-disabled-for-google-workspace-organization.asciidoc @@ -52,7 +52,7 @@ Multi-factor authentication (MFA) is a process in which users are prompted for a If you only use a password to authenticate a user, it leaves an insecure vector for attack. If the users's password is weak or has been exposed elsewhere, an attacker could use it to gain access. Requiring a second form of authentication increases security because attackers cannot easily obtain or duplicate the additional authentication factor. -For more information about using MFA in Google Workspace, access the [official documentation](https://support.google.com/a/answer/175197). +For more information about using MFA in Google Workspace, access the https://support.google.com/a/answer/175197. This rule identifies when MFA enforcement is turned off in Google Workspace. This modification weakens account security and can lead to accounts and other assets being compromised. @@ -81,7 +81,7 @@ This rule identifies when MFA enforcement is turned off in Google Workspace. Thi - 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. - Reactivate the multi-factor authentication enforcement. - Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. -- Implement security best practices [outlined](https://support.google.com/a/answer/7587183) by Google. +- Implement security best practices https://support.google.com/a/answer/7587183 by Google. - Determine 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). @@ -97,6 +97,14 @@ This rule identifies when MFA enforcement is turned off in Google Workspace. Thi - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/microsoft-365-exchange-anti-phish-policy-deletion.asciidoc b/docs/detections/prebuilt-rules/rule-details/microsoft-365-exchange-anti-phish-policy-deletion.asciidoc index c098901fb1..71906f06a8 100644 --- a/docs/detections/prebuilt-rules/rule-details/microsoft-365-exchange-anti-phish-policy-deletion.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/microsoft-365-exchange-anti-phish-policy-deletion.asciidoc @@ -49,6 +49,14 @@ Identifies the deletion of an anti-phishing policy in Microsoft 365. By default, ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/microsoft-365-exchange-anti-phish-rule-modification.asciidoc b/docs/detections/prebuilt-rules/rule-details/microsoft-365-exchange-anti-phish-rule-modification.asciidoc index d51d280a0f..e8ef48715d 100644 --- a/docs/detections/prebuilt-rules/rule-details/microsoft-365-exchange-anti-phish-rule-modification.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/microsoft-365-exchange-anti-phish-rule-modification.asciidoc @@ -49,6 +49,14 @@ Identifies the modification of an anti-phishing rule in Microsoft 365. By defaul ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/microsoft-365-exchange-dkim-signing-configuration-disabled.asciidoc b/docs/detections/prebuilt-rules/rule-details/microsoft-365-exchange-dkim-signing-configuration-disabled.asciidoc index ea42c677f4..b1092e898f 100644 --- a/docs/detections/prebuilt-rules/rule-details/microsoft-365-exchange-dkim-signing-configuration-disabled.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/microsoft-365-exchange-dkim-signing-configuration-disabled.asciidoc @@ -47,6 +47,14 @@ Identifies when a DomainKeys Identified Mail (DKIM) signing configuration is dis ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/microsoft-365-exchange-dlp-policy-removed.asciidoc b/docs/detections/prebuilt-rules/rule-details/microsoft-365-exchange-dlp-policy-removed.asciidoc index 949038eb11..33fcc51217 100644 --- a/docs/detections/prebuilt-rules/rule-details/microsoft-365-exchange-dlp-policy-removed.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/microsoft-365-exchange-dlp-policy-removed.asciidoc @@ -49,6 +49,14 @@ Identifies when a Data Loss Prevention (DLP) policy is removed in Microsoft 365. ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/microsoft-365-exchange-malware-filter-policy-deletion.asciidoc b/docs/detections/prebuilt-rules/rule-details/microsoft-365-exchange-malware-filter-policy-deletion.asciidoc index 69d56d7382..8304c39b95 100644 --- a/docs/detections/prebuilt-rules/rule-details/microsoft-365-exchange-malware-filter-policy-deletion.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/microsoft-365-exchange-malware-filter-policy-deletion.asciidoc @@ -48,6 +48,14 @@ Identifies when a malware filter policy has been deleted in Microsoft 365. A mal ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/microsoft-365-exchange-malware-filter-rule-modification.asciidoc b/docs/detections/prebuilt-rules/rule-details/microsoft-365-exchange-malware-filter-rule-modification.asciidoc index b1f37a4811..6d9e88e8cb 100644 --- a/docs/detections/prebuilt-rules/rule-details/microsoft-365-exchange-malware-filter-rule-modification.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/microsoft-365-exchange-malware-filter-rule-modification.asciidoc @@ -49,6 +49,14 @@ Identifies when a malware filter rule has been deleted or disabled in Microsoft ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/microsoft-365-exchange-management-group-role-assignment.asciidoc b/docs/detections/prebuilt-rules/rule-details/microsoft-365-exchange-management-group-role-assignment.asciidoc index 9630309c83..63f96c9b08 100644 --- a/docs/detections/prebuilt-rules/rule-details/microsoft-365-exchange-management-group-role-assignment.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/microsoft-365-exchange-management-group-role-assignment.asciidoc @@ -49,6 +49,14 @@ Identifies when a new role is assigned to a management group in Microsoft 365. A ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/microsoft-365-exchange-safe-attachment-rule-disabled.asciidoc b/docs/detections/prebuilt-rules/rule-details/microsoft-365-exchange-safe-attachment-rule-disabled.asciidoc index 95d5b855b8..01db77eb09 100644 --- a/docs/detections/prebuilt-rules/rule-details/microsoft-365-exchange-safe-attachment-rule-disabled.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/microsoft-365-exchange-safe-attachment-rule-disabled.asciidoc @@ -48,6 +48,14 @@ Identifies when a safe attachment rule is disabled in Microsoft 365. Safe attach ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/microsoft-365-exchange-safe-link-policy-disabled.asciidoc b/docs/detections/prebuilt-rules/rule-details/microsoft-365-exchange-safe-link-policy-disabled.asciidoc index e6f1cbbc17..cc18fc8ea7 100644 --- a/docs/detections/prebuilt-rules/rule-details/microsoft-365-exchange-safe-link-policy-disabled.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/microsoft-365-exchange-safe-link-policy-disabled.asciidoc @@ -49,6 +49,14 @@ Identifies when a Safe Link policy is disabled in Microsoft 365. Safe Link polic ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/microsoft-365-exchange-transport-rule-creation.asciidoc b/docs/detections/prebuilt-rules/rule-details/microsoft-365-exchange-transport-rule-creation.asciidoc index f4259ae208..d7053be920 100644 --- a/docs/detections/prebuilt-rules/rule-details/microsoft-365-exchange-transport-rule-creation.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/microsoft-365-exchange-transport-rule-creation.asciidoc @@ -49,6 +49,14 @@ Identifies a transport rule creation in Microsoft 365. As a best practice, Excha ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/microsoft-365-exchange-transport-rule-modification.asciidoc b/docs/detections/prebuilt-rules/rule-details/microsoft-365-exchange-transport-rule-modification.asciidoc index b1f7aa2c42..edb6cc979b 100644 --- a/docs/detections/prebuilt-rules/rule-details/microsoft-365-exchange-transport-rule-modification.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/microsoft-365-exchange-transport-rule-modification.asciidoc @@ -50,6 +50,14 @@ Identifies when a transport rule has been disabled or deleted in Microsoft 365. ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/microsoft-365-global-administrator-role-assigned.asciidoc b/docs/detections/prebuilt-rules/rule-details/microsoft-365-global-administrator-role-assigned.asciidoc index e8fd851fb0..a9cc1c2f73 100644 --- a/docs/detections/prebuilt-rules/rule-details/microsoft-365-global-administrator-role-assigned.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/microsoft-365-global-administrator-role-assigned.asciidoc @@ -48,6 +48,14 @@ In Azure Active Directory (Azure AD), permissions to manage resources are assign ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/microsoft-365-impossible-travel-activity.asciidoc b/docs/detections/prebuilt-rules/rule-details/microsoft-365-impossible-travel-activity.asciidoc index 390bc634a2..a7dd433f26 100644 --- a/docs/detections/prebuilt-rules/rule-details/microsoft-365-impossible-travel-activity.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/microsoft-365-impossible-travel-activity.asciidoc @@ -49,6 +49,14 @@ Identifies when a Microsoft Cloud App Security reported a risky sign-in attempt ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/microsoft-365-inbox-forwarding-rule-created.asciidoc b/docs/detections/prebuilt-rules/rule-details/microsoft-365-inbox-forwarding-rule-created.asciidoc index 5f7d1fdf59..7b1a3ed7f3 100644 --- a/docs/detections/prebuilt-rules/rule-details/microsoft-365-inbox-forwarding-rule-created.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/microsoft-365-inbox-forwarding-rule-created.asciidoc @@ -53,6 +53,14 @@ Identifies when a new Inbox forwarding rule is created in Microsoft 365. Inbox r ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/microsoft-365-mass-download-by-a-single-user.asciidoc b/docs/detections/prebuilt-rules/rule-details/microsoft-365-mass-download-by-a-single-user.asciidoc index 129e35eb1b..9cd4026572 100644 --- a/docs/detections/prebuilt-rules/rule-details/microsoft-365-mass-download-by-a-single-user.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/microsoft-365-mass-download-by-a-single-user.asciidoc @@ -49,6 +49,14 @@ Identifies when Microsoft Cloud App Security reports that a single user performs ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/microsoft-365-potential-ransomware-activity.asciidoc b/docs/detections/prebuilt-rules/rule-details/microsoft-365-potential-ransomware-activity.asciidoc index 6e6a08e29d..f08a36ceea 100644 --- a/docs/detections/prebuilt-rules/rule-details/microsoft-365-potential-ransomware-activity.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/microsoft-365-potential-ransomware-activity.asciidoc @@ -49,6 +49,14 @@ Identifies when Microsoft Cloud App Security reports that a user has uploaded fi ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/microsoft-365-teams-custom-application-interaction-allowed.asciidoc b/docs/detections/prebuilt-rules/rule-details/microsoft-365-teams-custom-application-interaction-allowed.asciidoc index ac0492d742..2e8d79354c 100644 --- a/docs/detections/prebuilt-rules/rule-details/microsoft-365-teams-custom-application-interaction-allowed.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/microsoft-365-teams-custom-application-interaction-allowed.asciidoc @@ -48,6 +48,14 @@ Identifies when custom applications are allowed in Microsoft Teams. If an organi ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/microsoft-365-teams-external-access-enabled.asciidoc b/docs/detections/prebuilt-rules/rule-details/microsoft-365-teams-external-access-enabled.asciidoc index 8eb262a597..e85049b44a 100644 --- a/docs/detections/prebuilt-rules/rule-details/microsoft-365-teams-external-access-enabled.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/microsoft-365-teams-external-access-enabled.asciidoc @@ -48,6 +48,14 @@ Identifies when external access is enabled in Microsoft Teams. External access l ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/microsoft-365-teams-guest-access-enabled.asciidoc b/docs/detections/prebuilt-rules/rule-details/microsoft-365-teams-guest-access-enabled.asciidoc index 4b30b8b6f1..9b614993a7 100644 --- a/docs/detections/prebuilt-rules/rule-details/microsoft-365-teams-guest-access-enabled.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/microsoft-365-teams-guest-access-enabled.asciidoc @@ -48,6 +48,14 @@ Identifies when guest access is enabled in Microsoft Teams. Guest access in Team ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/microsoft-365-unusual-volume-of-file-deletion.asciidoc b/docs/detections/prebuilt-rules/rule-details/microsoft-365-unusual-volume-of-file-deletion.asciidoc index 9a0d3d39ee..7405d1d6c7 100644 --- a/docs/detections/prebuilt-rules/rule-details/microsoft-365-unusual-volume-of-file-deletion.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/microsoft-365-unusual-volume-of-file-deletion.asciidoc @@ -49,6 +49,14 @@ Identifies that a user has deleted an unusually large volume of files as reporte ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/microsoft-365-user-restricted-from-sending-email.asciidoc b/docs/detections/prebuilt-rules/rule-details/microsoft-365-user-restricted-from-sending-email.asciidoc index bd62a33794..adbff834e9 100644 --- a/docs/detections/prebuilt-rules/rule-details/microsoft-365-user-restricted-from-sending-email.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/microsoft-365-user-restricted-from-sending-email.asciidoc @@ -49,6 +49,14 @@ Identifies when a user has been restricted from sending email due to exceeding s ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/microsoft-build-engine-started-an-unusual-process.asciidoc b/docs/detections/prebuilt-rules/rule-details/microsoft-build-engine-started-an-unusual-process.asciidoc index c9f9b6a55e..b1b33a6360 100644 --- a/docs/detections/prebuilt-rules/rule-details/microsoft-build-engine-started-an-unusual-process.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/microsoft-build-engine-started-an-unusual-process.asciidoc @@ -44,6 +44,20 @@ An instance of MSBuild, the Microsoft Build Engine, started a PowerShell script *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/microsoft-build-engine-started-by-a-script-process.asciidoc b/docs/detections/prebuilt-rules/rule-details/microsoft-build-engine-started-by-a-script-process.asciidoc index 20e4320df9..1c98018fb9 100644 --- a/docs/detections/prebuilt-rules/rule-details/microsoft-build-engine-started-by-a-script-process.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/microsoft-build-engine-started-by-a-script-process.asciidoc @@ -41,6 +41,20 @@ An instance of MSBuild, the Microsoft Build Engine, was started by a script or t *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/microsoft-build-engine-started-by-a-system-process.asciidoc b/docs/detections/prebuilt-rules/rule-details/microsoft-build-engine-started-by-a-system-process.asciidoc index f819f9930e..fb1823060c 100644 --- a/docs/detections/prebuilt-rules/rule-details/microsoft-build-engine-started-by-a-system-process.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/microsoft-build-engine-started-by-a-system-process.asciidoc @@ -43,6 +43,20 @@ An instance of MSBuild, the Microsoft Build Engine, was started by Explorer or t *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/microsoft-build-engine-started-by-an-office-application.asciidoc b/docs/detections/prebuilt-rules/rule-details/microsoft-build-engine-started-by-an-office-application.asciidoc index 71fb6372a7..a3e36ed3b3 100644 --- a/docs/detections/prebuilt-rules/rule-details/microsoft-build-engine-started-by-an-office-application.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/microsoft-build-engine-started-by-an-office-application.asciidoc @@ -102,6 +102,20 @@ This rule looks for the `Msbuild.exe` utility spawned by MS Office programs. Thi - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/microsoft-build-engine-using-an-alternate-name.asciidoc b/docs/detections/prebuilt-rules/rule-details/microsoft-build-engine-using-an-alternate-name.asciidoc index 5ecbbe23a5..027af85f7e 100644 --- a/docs/detections/prebuilt-rules/rule-details/microsoft-build-engine-using-an-alternate-name.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/microsoft-build-engine-using-an-alternate-name.asciidoc @@ -60,7 +60,7 @@ The Microsoft Build Engine is a platform for building applications. This engine, This rule checks for renamed instances of MSBuild, which can indicate an attempt of evading detections, application allowlists, and other security protections. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps @@ -100,6 +100,20 @@ This rule checks for renamed instances of MSBuild, which can indicate an attempt - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/microsoft-exchange-server-um-spawning-suspicious-processes.asciidoc b/docs/detections/prebuilt-rules/rule-details/microsoft-exchange-server-um-spawning-suspicious-processes.asciidoc index 5914cd699d..52aa198c8d 100644 --- a/docs/detections/prebuilt-rules/rule-details/microsoft-exchange-server-um-spawning-suspicious-processes.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/microsoft-exchange-server-um-spawning-suspicious-processes.asciidoc @@ -49,6 +49,20 @@ Identifies suspicious processes being spawned by the Microsoft Exchange Server U *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/microsoft-exchange-server-um-writing-suspicious-files.asciidoc b/docs/detections/prebuilt-rules/rule-details/microsoft-exchange-server-um-writing-suspicious-files.asciidoc index a73c56635f..7609b0c64e 100644 --- a/docs/detections/prebuilt-rules/rule-details/microsoft-exchange-server-um-writing-suspicious-files.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/microsoft-exchange-server-um-writing-suspicious-files.asciidoc @@ -55,14 +55,28 @@ Identifies suspicious files being written by the Microsoft Exchange Server Unifi ---------------------------------- ## Triage and analysis -Positive hits can be checked against the established Microsoft [baselines](https://github.com/microsoft/CSS-Exchange/tree/main/Security/Baselines). +Positive hits can be checked against the established Microsoft https://github.com/microsoft/CSS-Exchange/tree/main/Security/Baselines. Microsoft highly recommends that the best course of action is patching, but this may not protect already compromised systems from existing intrusions. Other tools for detecting and mitigating can be found within their Exchange support -[repository](https://github.com/microsoft/CSS-Exchange/tree/main/Security) +https://github.com/microsoft/CSS-Exchange/tree/main/Security +---------------------------------- + +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/microsoft-exchange-transport-agent-install-script.asciidoc b/docs/detections/prebuilt-rules/rule-details/microsoft-exchange-transport-agent-install-script.asciidoc index edbd831281..eed34a630e 100644 --- a/docs/detections/prebuilt-rules/rule-details/microsoft-exchange-transport-agent-install-script.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/microsoft-exchange-transport-agent-install-script.asciidoc @@ -40,6 +40,27 @@ Identifies the use of Cmdlets and methods related to Microsoft Exchange Transpor *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +The 'PowerShell Script Block Logging' logging policy must be enabled. +Steps to implement the logging policy with Advanced Audit Configuration: +``` +Computer Configuration > +Administrative Templates > +Windows PowerShell > +Turn on PowerShell Script Block Logging (Enable) +``` +Steps to implement the logging policy via registry: +``` +reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1 +``` + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/microsoft-exchange-worker-spawning-suspicious-processes.asciidoc b/docs/detections/prebuilt-rules/rule-details/microsoft-exchange-worker-spawning-suspicious-processes.asciidoc index 0cce934fe6..4c1cc671d4 100644 --- a/docs/detections/prebuilt-rules/rule-details/microsoft-exchange-worker-spawning-suspicious-processes.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/microsoft-exchange-worker-spawning-suspicious-processes.asciidoc @@ -47,6 +47,20 @@ Identifies suspicious processes being spawned by the Microsoft Exchange Server w *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/microsoft-iis-connection-strings-decryption.asciidoc b/docs/detections/prebuilt-rules/rule-details/microsoft-iis-connection-strings-decryption.asciidoc index d151e31a1d..2c3b38a806 100644 --- a/docs/detections/prebuilt-rules/rule-details/microsoft-iis-connection-strings-decryption.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/microsoft-iis-connection-strings-decryption.asciidoc @@ -46,6 +46,20 @@ Identifies use of aspnet_regiis to decrypt Microsoft IIS connection strings. An *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/microsoft-iis-service-account-password-dumped.asciidoc b/docs/detections/prebuilt-rules/rule-details/microsoft-iis-service-account-password-dumped.asciidoc index 06ad200258..45eb0ee7f2 100644 --- a/docs/detections/prebuilt-rules/rule-details/microsoft-iis-service-account-password-dumped.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/microsoft-iis-service-account-password-dumped.asciidoc @@ -45,6 +45,20 @@ Identifies the Internet Information Services (IIS) command-line tool, AppCmd, be *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/microsoft-windows-defender-tampering.asciidoc b/docs/detections/prebuilt-rules/rule-details/microsoft-windows-defender-tampering.asciidoc index 8409cd0c4b..e314fb0e8c 100644 --- a/docs/detections/prebuilt-rules/rule-details/microsoft-windows-defender-tampering.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/microsoft-windows-defender-tampering.asciidoc @@ -93,6 +93,20 @@ This rule monitors the registry for modifications that disable Windows Defender - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/mimikatz-memssp-log-file-detected.asciidoc b/docs/detections/prebuilt-rules/rule-details/mimikatz-memssp-log-file-detected.asciidoc index 2baad222c2..9547864b2a 100644 --- a/docs/detections/prebuilt-rules/rule-details/mimikatz-memssp-log-file-detected.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/mimikatz-memssp-log-file-detected.asciidoc @@ -54,7 +54,7 @@ Identifies the password log file from the default Mimikatz memssp module. ### Investigating Mimikatz Memssp Log File Detected -[Mimikatz](https://github.com/gentilkiwi/mimikatz) is an open-source tool used to collect, decrypt, and/or use cached credentials. This tool is commonly abused by adversaries during the post-compromise stage where adversaries have gained an initial foothold on an endpoint and are looking to elevate privileges and seek out additional authentication objects such as tokens/hashes/credentials that can then be used to laterally move and pivot across a network. +https://github.com/gentilkiwi/mimikatz is an open-source tool used to collect, decrypt, and/or use cached credentials. This tool is commonly abused by adversaries during the post-compromise stage where adversaries have gained an initial foothold on an endpoint and are looking to elevate privileges and seek out additional authentication objects such as tokens/hashes/credentials that can then be used to laterally move and pivot across a network. This rule looks for the creation of a file named `mimilsa.log`, which is generated when using the Mimikatz misc::memssp module, which injects a malicious Windows SSP to collect locally authenticated credentials, which includes the computer account password, running service credentials, and any accounts that logon. @@ -92,6 +92,20 @@ This rule looks for the creation of a file named `mimilsa.log`, which is generat - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/modification-of-amsienable-registry-key.asciidoc b/docs/detections/prebuilt-rules/rule-details/modification-of-amsienable-registry-key.asciidoc index 0acffbda10..9d2f9fab36 100644 --- a/docs/detections/prebuilt-rules/rule-details/modification-of-amsienable-registry-key.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/modification-of-amsienable-registry-key.asciidoc @@ -102,6 +102,20 @@ This rule monitors the modifications to the Software\Microsoft\Windows Script\Se - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/modification-of-boot-configuration.asciidoc b/docs/detections/prebuilt-rules/rule-details/modification-of-boot-configuration.asciidoc index 4d751abecc..40f9995514 100644 --- a/docs/detections/prebuilt-rules/rule-details/modification-of-boot-configuration.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/modification-of-boot-configuration.asciidoc @@ -88,6 +88,20 @@ These are common steps in destructive attacks by adversaries leveraging ransomwa - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/modification-of-dynamic-linker-preload-shared-object.asciidoc b/docs/detections/prebuilt-rules/rule-details/modification-of-dynamic-linker-preload-shared-object.asciidoc index 19a6d8c5c3..e63e0d61ab 100644 --- a/docs/detections/prebuilt-rules/rule-details/modification-of-dynamic-linker-preload-shared-object.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/modification-of-dynamic-linker-preload-shared-object.asciidoc @@ -43,6 +43,50 @@ Identifies modification of the dynamic linker preload shared object (ld.so.prelo *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Auditbeat + +### 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. + +#### 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. +- 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. +- 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. + +### Auditbeat Setup +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + +#### The following steps should be executed in order to add the Auditbeat on a Linux System: +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/modification-of-environment-variable-via-launchctl.asciidoc b/docs/detections/prebuilt-rules/rule-details/modification-of-environment-variable-via-launchctl.asciidoc index b61e2ba0c9..3d70de3d20 100644 --- a/docs/detections/prebuilt-rules/rule-details/modification-of-environment-variable-via-launchctl.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/modification-of-environment-variable-via-launchctl.asciidoc @@ -40,6 +40,38 @@ Identifies modifications to an environment variable using the built-in launchctl *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### The following steps should be executed in order to add the Elastic Defend integration on a macOS 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, for MacOS it is recommended to select "Traditional Endpoints". +- 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/modification-of-openssh-binaries.asciidoc b/docs/detections/prebuilt-rules/rule-details/modification-of-openssh-binaries.asciidoc index 937700080c..63a00449a5 100644 --- a/docs/detections/prebuilt-rules/rule-details/modification-of-openssh-binaries.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/modification-of-openssh-binaries.asciidoc @@ -61,8 +61,8 @@ Adversaries may exploit OpenSSH by modifying its binaries, such as `/usr/bin/scp The detection rule 'Modification of OpenSSH Binaries' is designed to identify such abuse by monitoring file changes in the Linux environment. It triggers an alert when a process, modifies any of the specified OpenSSH binaries or libraries. This helps security analysts detect potential malicious activities and take appropriate action. > **Note**: -> This investigation guide uses the {security-guide}/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. -> This investigation guide uses {security-guide}/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. ### Possible investigation steps @@ -110,6 +110,50 @@ The detection rule 'Modification of OpenSSH Binaries' is designed to identify su - Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. - Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). +---------------------------------- + +==== Setup + + +[source, markdown] +---------------------------------- + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Auditbeat + +### 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. + +#### 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. +- 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. +- 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. + +### Auditbeat Setup +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + +#### The following steps should be executed in order to add the Auditbeat on a Linux System: +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html. + + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/modification-of-safari-settings-via-defaults-command.asciidoc b/docs/detections/prebuilt-rules/rule-details/modification-of-safari-settings-via-defaults-command.asciidoc index 6f3385371c..cb181ff0fc 100644 --- a/docs/detections/prebuilt-rules/rule-details/modification-of-safari-settings-via-defaults-command.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/modification-of-safari-settings-via-defaults-command.asciidoc @@ -40,6 +40,38 @@ Identifies changes to the Safari configuration using the built-in defaults comma *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### The following steps should be executed in order to add the Elastic Defend integration on a macOS 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, for MacOS it is recommended to select "Traditional Endpoints". +- 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/modification-of-the-mspkiaccountcredentials.asciidoc b/docs/detections/prebuilt-rules/rule-details/modification-of-the-mspkiaccountcredentials.asciidoc index 18a7ec1b76..d070f78e02 100644 --- a/docs/detections/prebuilt-rules/rule-details/modification-of-the-mspkiaccountcredentials.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/modification-of-the-mspkiaccountcredentials.asciidoc @@ -45,6 +45,28 @@ Identify the modification of the msPKIAccountCredentials attribute in an Active *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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) +``` + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/modification-of-wdigest-security-provider.asciidoc b/docs/detections/prebuilt-rules/rule-details/modification-of-wdigest-security-provider.asciidoc index e4bfe831d6..447643b713 100644 --- a/docs/detections/prebuilt-rules/rule-details/modification-of-wdigest-security-provider.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/modification-of-wdigest-security-provider.asciidoc @@ -97,6 +97,20 @@ Still, attackers can force WDigest to store the passwords insecurely on the memo - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/modification-or-removal-of-an-okta-application-sign-on-policy.asciidoc b/docs/detections/prebuilt-rules/rule-details/modification-or-removal-of-an-okta-application-sign-on-policy.asciidoc index dede3f41ae..f516787303 100644 --- a/docs/detections/prebuilt-rules/rule-details/modification-or-removal-of-an-okta-application-sign-on-policy.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/modification-or-removal-of-an-okta-application-sign-on-policy.asciidoc @@ -50,6 +50,14 @@ Detects attempts to modify or delete a sign on policy for an Okta application. A ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/mounting-hidden-or-webdav-remote-shares.asciidoc b/docs/detections/prebuilt-rules/rule-details/mounting-hidden-or-webdav-remote-shares.asciidoc index f323a1491b..a22cea2280 100644 --- a/docs/detections/prebuilt-rules/rule-details/mounting-hidden-or-webdav-remote-shares.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/mounting-hidden-or-webdav-remote-shares.asciidoc @@ -43,6 +43,20 @@ Identifies the use of net.exe to mount a WebDav or hidden remote share. This may *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/ms-office-macro-security-registry-modifications.asciidoc b/docs/detections/prebuilt-rules/rule-details/ms-office-macro-security-registry-modifications.asciidoc index 9dc6f99d6f..55742392fd 100644 --- a/docs/detections/prebuilt-rules/rule-details/ms-office-macro-security-registry-modifications.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/ms-office-macro-security-registry-modifications.asciidoc @@ -95,6 +95,20 @@ This rule looks for registry changes affecting the conditions above. +---------------------------------- + +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/msbuild-making-network-connections.asciidoc b/docs/detections/prebuilt-rules/rule-details/msbuild-making-network-connections.asciidoc index e1c2cb0128..cb60aa42be 100644 --- a/docs/detections/prebuilt-rules/rule-details/msbuild-making-network-connections.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/msbuild-making-network-connections.asciidoc @@ -57,7 +57,7 @@ The Microsoft Build Engine, also known as MSBuild, is a platform for building ap This rule looks for the `Msbuild.exe` utility execution, followed by a network connection to an external address. Attackers can abuse MsBuild to execute malicious files or masquerade as those utilities in order to bypass detections and evade defenses. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps diff --git a/docs/detections/prebuilt-rules/rule-details/multi-factor-authentication-disabled-for-an-azure-user.asciidoc b/docs/detections/prebuilt-rules/rule-details/multi-factor-authentication-disabled-for-an-azure-user.asciidoc index 9e8010496e..1e2e390623 100644 --- a/docs/detections/prebuilt-rules/rule-details/multi-factor-authentication-disabled-for-an-azure-user.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/multi-factor-authentication-disabled-for-an-azure-user.asciidoc @@ -52,7 +52,7 @@ Multi-factor authentication is a process in which users are prompted during the If you only use a password to authenticate a user, it leaves an insecure vector for attack. If the password is weak or has been exposed elsewhere, an attacker could be using it to gain access. When you require a second form of authentication, security is increased because this additional factor isn't something that's easy for an attacker to obtain or duplicate. -For more information about using MFA in Azure AD, access the [official documentation](https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-mfa-howitworks#how-to-enable-and-use-azure-ad-multi-factor-authentication). +For more information about using MFA in Azure AD, access the https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-mfa-howitworks#how-to-enable-and-use-azure-ad-multi-factor-authentication. This rule identifies the deactivation of MFA for an Azure user account. This modification weakens account security and can lead to the compromise of accounts and other assets. @@ -81,11 +81,19 @@ This rule identifies the deactivation of MFA for an Azure user account. This mod - 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. - Reactivate multi-factor authentication for the user. - Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed. -- Implement security defaults [provided by Microsoft](https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/concept-fundamentals-security-defaults). +- Implement security defaults https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/concept-fundamentals-security-defaults. - Determine 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 + + +[source, markdown] +---------------------------------- +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/multiple-logon-failure-followed-by-logon-success.asciidoc b/docs/detections/prebuilt-rules/rule-details/multiple-logon-failure-followed-by-logon-success.asciidoc index 933d0e994f..b65af8eec6 100644 --- a/docs/detections/prebuilt-rules/rule-details/multiple-logon-failure-followed-by-logon-success.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/multiple-logon-failure-followed-by-logon-success.asciidoc @@ -51,12 +51,12 @@ Identifies multiple logon failures followed by a successful one from the same so ### Investigating Multiple Logon Failure Followed by Logon Success -Adversaries with no prior knowledge of legitimate credentials within the system or environment may guess passwords to attempt access to accounts. Without knowledge of the password for an account, an adversary may opt to guess the password using a repetitive or iterative mechanism systematically. More details can be found [here](https://attack.mitre.org/techniques/T1110/001/). +Adversaries with no prior knowledge of legitimate credentials within the system or environment may guess passwords to attempt access to accounts. Without knowledge of the password for an account, an adversary may opt to guess the password using a repetitive or iterative mechanism systematically. More details can be found https://attack.mitre.org/techniques/T1110/001/. This rule identifies potential password guessing/brute force activity from a single address, followed by a successful logon, indicating that an attacker potentially successfully compromised the account. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps @@ -101,6 +101,20 @@ This rule identifies potential password guessing/brute force activity from a sin - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/multiple-logon-failure-from-the-same-source-address.asciidoc b/docs/detections/prebuilt-rules/rule-details/multiple-logon-failure-from-the-same-source-address.asciidoc index e70da27de6..7c43cce942 100644 --- a/docs/detections/prebuilt-rules/rule-details/multiple-logon-failure-from-the-same-source-address.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/multiple-logon-failure-from-the-same-source-address.asciidoc @@ -54,12 +54,12 @@ Identifies multiple consecutive logon failures from the same source address and ### Investigating Multiple Logon Failure from the same Source Address -Adversaries with no prior knowledge of legitimate credentials within the system or environment may guess passwords to attempt access to accounts. Without knowledge of the password for an account, an adversary may opt to guess the password using a repetitive or iterative mechanism systematically. More details can be found [here](https://attack.mitre.org/techniques/T1110/001/). +Adversaries with no prior knowledge of legitimate credentials within the system or environment may guess passwords to attempt access to accounts. Without knowledge of the password for an account, an adversary may opt to guess the password using a repetitive or iterative mechanism systematically. More details can be found https://attack.mitre.org/techniques/T1110/001/. This rule identifies potential password guessing/brute force activity from a single address. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps @@ -105,6 +105,16 @@ This rule identifies potential password guessing/brute force activity from a sin - 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 + + +[source, markdown] +---------------------------------- + +- In some cases the source network address in Windows events 4625/4624 is not populated due to Microsoft logging limitations (examples in the references links). This edge case will break the rule condition and it won't trigger an alert. + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/multiple-okta-client-addresses-for-a-single-user-session.asciidoc b/docs/detections/prebuilt-rules/rule-details/multiple-okta-client-addresses-for-a-single-user-session.asciidoc index 2edccb5f57..149ff32341 100644 --- a/docs/detections/prebuilt-rules/rule-details/multiple-okta-client-addresses-for-a-single-user-session.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/multiple-okta-client-addresses-for-a-single-user-session.asciidoc @@ -50,6 +50,14 @@ Detects when a user has started multiple Okta sessions with the same user accoun ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/multiple-okta-sessions-detected-for-a-single-user.asciidoc b/docs/detections/prebuilt-rules/rule-details/multiple-okta-sessions-detected-for-a-single-user.asciidoc index 734b164369..ab796b4d53 100644 --- a/docs/detections/prebuilt-rules/rule-details/multiple-okta-sessions-detected-for-a-single-user.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/multiple-okta-sessions-detected-for-a-single-user.asciidoc @@ -50,6 +50,14 @@ Detects when a user has started multiple Okta sessions with the same user accoun ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/multiple-okta-user-auth-events-with-same-device-token-hash-behind-a-proxy.asciidoc b/docs/detections/prebuilt-rules/rule-details/multiple-okta-user-auth-events-with-same-device-token-hash-behind-a-proxy.asciidoc index a6637d3049..7c35a9bbed 100644 --- a/docs/detections/prebuilt-rules/rule-details/multiple-okta-user-auth-events-with-same-device-token-hash-behind-a-proxy.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/multiple-okta-user-auth-events-with-same-device-token-hash-behind-a-proxy.asciidoc @@ -91,6 +91,14 @@ This rule detects when Okta user authentication events are reported for multiple ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/multiple-vault-web-credentials-read.asciidoc b/docs/detections/prebuilt-rules/rule-details/multiple-vault-web-credentials-read.asciidoc index 67222ec616..77922e8364 100644 --- a/docs/detections/prebuilt-rules/rule-details/multiple-vault-web-credentials-read.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/multiple-vault-web-credentials-read.asciidoc @@ -42,6 +42,20 @@ Windows Credential Manager allows you to create, view, or delete saved credentia *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/namespace-manipulation-using-unshare.asciidoc b/docs/detections/prebuilt-rules/rule-details/namespace-manipulation-using-unshare.asciidoc index 0bdd6d615b..c19da2dd97 100644 --- a/docs/detections/prebuilt-rules/rule-details/namespace-manipulation-using-unshare.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/namespace-manipulation-using-unshare.asciidoc @@ -44,6 +44,50 @@ Identifies suspicious usage of unshare to manipulate system namespaces. Unshare *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Auditbeat + +### 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. + +#### 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. +- 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. +- 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. + +### Auditbeat Setup +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + +#### The following steps should be executed in order to add the Auditbeat on a Linux System: +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/netcat-listener-established-via-rlwrap.asciidoc b/docs/detections/prebuilt-rules/rule-details/netcat-listener-established-via-rlwrap.asciidoc index 14720f3970..c5b9591d15 100644 --- a/docs/detections/prebuilt-rules/rule-details/netcat-listener-established-via-rlwrap.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/netcat-listener-established-via-rlwrap.asciidoc @@ -38,6 +38,39 @@ Monitors for the execution of a netcat listener via rlwrap. rlwrap is a 'readlin *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- We suggest to select "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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/network-activity-detected-via-cat.asciidoc b/docs/detections/prebuilt-rules/rule-details/network-activity-detected-via-cat.asciidoc index 59b8193224..76f2c52d78 100644 --- a/docs/detections/prebuilt-rules/rule-details/network-activity-detected-via-cat.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/network-activity-detected-via-cat.asciidoc @@ -52,8 +52,8 @@ Attackers may leverage the `cat` utility in conjunction with a listener to read This rule looks for a sequence of a `cat` execution event followed by a network connection attempt by the same `cat` process. > **Note**: -> This investigation guide uses the {security-guide}/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. -> This investigation guide uses {security-guide}/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. #### Possible investigation steps @@ -103,6 +103,36 @@ This rule looks for a sequence of a `cat` execution event followed by a network ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +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. + +#### 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. +- 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. +- 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. + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/network-activity-detected-via-kworker.asciidoc b/docs/detections/prebuilt-rules/rule-details/network-activity-detected-via-kworker.asciidoc index b99e0bee5c..d21ef05d12 100644 --- a/docs/detections/prebuilt-rules/rule-details/network-activity-detected-via-kworker.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/network-activity-detected-via-kworker.asciidoc @@ -38,6 +38,39 @@ This rule monitors for network connections from a kworker process. kworker, or k *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- We suggest to select "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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/network-connection-via-certutil.asciidoc b/docs/detections/prebuilt-rules/rule-details/network-connection-via-certutil.asciidoc index 3aa567dafc..2cef648ddc 100644 --- a/docs/detections/prebuilt-rules/rule-details/network-connection-via-certutil.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/network-connection-via-certutil.asciidoc @@ -55,11 +55,11 @@ Identifies certutil.exe making a network connection. Adversaries could abuse cer Attackers can abuse `certutil.exe` to download malware, offensive security tools, and certificates from external sources in order to take the next steps in a compromised environment. -This rule looks for network events where `certutil.exe` contacts IP ranges other than the ones specified in [IANA IPv4 Special-Purpose Address Registry](https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml) +This rule looks for network events where `certutil.exe` contacts IP ranges other than the ones specified in https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml > **Note**: -> This investigation guide uses the {security-guide}/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. -> This investigation guide uses the {security-guide}/security/master/interactive-investigation-guides.html[Investigate Markdown Plugin] introduced in Elastic Stack version 8.8.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/interactive-investigation-guides.html introduced in Elastic Stack version 8.8.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps diff --git a/docs/detections/prebuilt-rules/rule-details/network-connection-via-compiled-html-file.asciidoc b/docs/detections/prebuilt-rules/rule-details/network-connection-via-compiled-html-file.asciidoc index aedcdecd8d..884a3ce237 100644 --- a/docs/detections/prebuilt-rules/rule-details/network-connection-via-compiled-html-file.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/network-connection-via-compiled-html-file.asciidoc @@ -59,7 +59,7 @@ When users double-click CHM files, the HTML Help executable program (`hh.exe`) w This rule identifies network connections done by `hh.exe`, which can potentially indicate abuse to download malicious files or tooling, or masquerading. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps diff --git a/docs/detections/prebuilt-rules/rule-details/network-connection-via-recently-compiled-executable.asciidoc b/docs/detections/prebuilt-rules/rule-details/network-connection-via-recently-compiled-executable.asciidoc index 76531ee65e..41e90867ad 100644 --- a/docs/detections/prebuilt-rules/rule-details/network-connection-via-recently-compiled-executable.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/network-connection-via-recently-compiled-executable.asciidoc @@ -38,6 +38,38 @@ This rule monitors a sequence involving a program compilation event followed by *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/network-connection-via-registration-utility.asciidoc b/docs/detections/prebuilt-rules/rule-details/network-connection-via-registration-utility.asciidoc index aa8caba6a7..ac882237ca 100644 --- a/docs/detections/prebuilt-rules/rule-details/network-connection-via-registration-utility.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/network-connection-via-registration-utility.asciidoc @@ -58,7 +58,7 @@ By examining the specific traits of Windows binaries -- such as process trees, c This rule looks for the execution of `regsvr32.exe`, `RegAsm.exe`, or `RegSvcs.exe` utilities followed by a network connection to an external address. Attackers can abuse utilities to execute malicious files or masquerade as those utilities in order to bypass detections and evade defenses. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps diff --git a/docs/detections/prebuilt-rules/rule-details/network-connection-via-signed-binary.asciidoc b/docs/detections/prebuilt-rules/rule-details/network-connection-via-signed-binary.asciidoc index a6c46ab537..2958d08da7 100644 --- a/docs/detections/prebuilt-rules/rule-details/network-connection-via-signed-binary.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/network-connection-via-signed-binary.asciidoc @@ -57,7 +57,7 @@ By examining the specific traits of Windows binaries (such as process trees, com This rule looks for the execution of `expand.exe`, `extrac32.exe`, `ieexec.exe`, or `makecab.exe` utilities, followed by a network connection to an external address. Attackers can abuse utilities to execute malicious files or masquerade as those utilities to bypass detections and evade defenses. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps diff --git a/docs/detections/prebuilt-rules/rule-details/network-logon-provider-registry-modification.asciidoc b/docs/detections/prebuilt-rules/rule-details/network-logon-provider-registry-modification.asciidoc index e589f77d9a..329af9e1ec 100644 --- a/docs/detections/prebuilt-rules/rule-details/network-logon-provider-registry-modification.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/network-logon-provider-registry-modification.asciidoc @@ -58,7 +58,7 @@ Network logon providers are components in Windows responsible for handling the a This rule identifies the modification of the network logon provider registry. Adversaries may register a rogue network logon provider module for persistence and/or credential access via intercepting the authentication credentials in plain text during user logon. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. ### Possible investigation steps diff --git a/docs/detections/prebuilt-rules/rule-details/network-traffic-capture-via-cap-net-raw.asciidoc b/docs/detections/prebuilt-rules/rule-details/network-traffic-capture-via-cap-net-raw.asciidoc index ef0695b63a..cdbb74b907 100644 --- a/docs/detections/prebuilt-rules/rule-details/network-traffic-capture-via-cap-net-raw.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/network-traffic-capture-via-cap-net-raw.asciidoc @@ -38,6 +38,38 @@ Identifies the ability of a process to be able to create RAW and PACKET socket t *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/new-activesyncalloweddeviceid-added-via-powershell.asciidoc b/docs/detections/prebuilt-rules/rule-details/new-activesyncalloweddeviceid-added-via-powershell.asciidoc index 775d4fcb3d..346167ad1e 100644 --- a/docs/detections/prebuilt-rules/rule-details/new-activesyncalloweddeviceid-added-via-powershell.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/new-activesyncalloweddeviceid-added-via-powershell.asciidoc @@ -46,6 +46,20 @@ Identifies the use of the Exchange PowerShell cmdlet, Set-CASMailbox, to add a n *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/new-okta-authentication-behavior-detected.asciidoc b/docs/detections/prebuilt-rules/rule-details/new-okta-authentication-behavior-detected.asciidoc index 81c6c6dd96..2b77e9a3ce 100644 --- a/docs/detections/prebuilt-rules/rule-details/new-okta-authentication-behavior-detected.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/new-okta-authentication-behavior-detected.asciidoc @@ -76,6 +76,14 @@ This rule detects events where Okta behavior detection has identified a new auth - Conduct a review of Okta policies and ensure they are in accordance with security best practices. ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/new-okta-identity-provider-idp-added-by-admin.asciidoc b/docs/detections/prebuilt-rules/rule-details/new-okta-identity-provider-idp-added-by-admin.asciidoc index 7dd2daeb8c..c79681d1a2 100644 --- a/docs/detections/prebuilt-rules/rule-details/new-okta-identity-provider-idp-added-by-admin.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/new-okta-identity-provider-idp-added-by-admin.asciidoc @@ -77,6 +77,14 @@ This rule detects the creation of a new Identity Provider (IdP) by a Super Admin - If the deactivated IdP was crucial to the organization, consider adding a new IdP and removing the unauthorized IdP. ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/new-or-modified-federation-domain.asciidoc b/docs/detections/prebuilt-rules/rule-details/new-or-modified-federation-domain.asciidoc index f208aa691a..c977d6f0d6 100644 --- a/docs/detections/prebuilt-rules/rule-details/new-or-modified-federation-domain.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/new-or-modified-federation-domain.asciidoc @@ -53,6 +53,14 @@ Identifies a new or modified federation domain, which can be used to create a tr ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/new-systemd-service-created-by-previously-unknown-process.asciidoc b/docs/detections/prebuilt-rules/rule-details/new-systemd-service-created-by-previously-unknown-process.asciidoc index a3ae97e674..a41fe33c3f 100644 --- a/docs/detections/prebuilt-rules/rule-details/new-systemd-service-created-by-previously-unknown-process.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/new-systemd-service-created-by-previously-unknown-process.asciidoc @@ -60,8 +60,8 @@ Malicious actors can leverage systemd service files to achieve persistence by cr This rule monitors the creation of new systemd service files, potentially indicating the creation of a persistence mechanism. > **Note**: -> This investigation guide uses the {security-guide}/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. -> This investigation guide uses {security-guide}/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. #### Possible Investigation Steps @@ -121,6 +121,38 @@ This rule monitors the creation of new systemd service files, potentially indica - Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. - Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). +---------------------------------- + +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/new-systemd-timer-created.asciidoc b/docs/detections/prebuilt-rules/rule-details/new-systemd-timer-created.asciidoc index 247dbae086..17603f6dfb 100644 --- a/docs/detections/prebuilt-rules/rule-details/new-systemd-timer-created.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/new-systemd-timer-created.asciidoc @@ -60,8 +60,8 @@ Attackers can leverage systemd timers to run scripts, commands, or malicious sof This rule monitors the creation of new systemd timer files, potentially indicating the creation of a persistence mechanism. > **Note**: -> This investigation guide uses the {security-guide}/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. -> This investigation guide uses {security-guide}/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. #### Possible Investigation Steps @@ -109,6 +109,38 @@ This rule monitors the creation of new systemd timer files, potentially indicati - Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). +---------------------------------- + +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/nping-process-activity.asciidoc b/docs/detections/prebuilt-rules/rule-details/nping-process-activity.asciidoc index 63c8ef8ff4..28c5001fee 100644 --- a/docs/detections/prebuilt-rules/rule-details/nping-process-activity.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/nping-process-activity.asciidoc @@ -43,6 +43,50 @@ Nping ran on a Linux host. Nping is part of the Nmap tool suite and has the abil *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Auditbeat + +### 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. + +#### 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. +- 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. +- 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. + +### Auditbeat Setup +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + +#### The following steps should be executed in order to add the Auditbeat on a Linux System: +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/ntds-or-sam-database-file-copied.asciidoc b/docs/detections/prebuilt-rules/rule-details/ntds-or-sam-database-file-copied.asciidoc index bbe7ba0028..cc35923020 100644 --- a/docs/detections/prebuilt-rules/rule-details/ntds-or-sam-database-file-copied.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/ntds-or-sam-database-file-copied.asciidoc @@ -62,7 +62,7 @@ The Active Directory Domain Database (ntds.dit) and Security Account Manager (SA This rule identifies copy operations of these files using specific command-line tools, such as Cmd.Exe, PowerShell.EXE, XCOPY.EXE, and esentutl.exe. By monitoring for the presence of these tools and their associated arguments, the rule aims to detect potential credential access activities. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. ### Possible investigation steps @@ -111,6 +111,20 @@ This rule identifies copy operations of these files using specific command-line ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/o365-email-reported-by-user-as-malware-or-phish.asciidoc b/docs/detections/prebuilt-rules/rule-details/o365-email-reported-by-user-as-malware-or-phish.asciidoc index 76b61db1c8..5076f6b2d0 100644 --- a/docs/detections/prebuilt-rules/rule-details/o365-email-reported-by-user-as-malware-or-phish.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/o365-email-reported-by-user-as-malware-or-phish.asciidoc @@ -47,6 +47,14 @@ Detects the occurrence of emails reported as Phishing or Malware by Users. Secur ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/o365-excessive-single-sign-on-logon-errors.asciidoc b/docs/detections/prebuilt-rules/rule-details/o365-excessive-single-sign-on-logon-errors.asciidoc index f4d9dcdb04..bd4e3fddf7 100644 --- a/docs/detections/prebuilt-rules/rule-details/o365-excessive-single-sign-on-logon-errors.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/o365-excessive-single-sign-on-logon-errors.asciidoc @@ -47,6 +47,14 @@ Identifies accounts with a high number of single sign-on (SSO) logon errors. Exc ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/o365-exchange-suspicious-mailbox-right-delegation.asciidoc b/docs/detections/prebuilt-rules/rule-details/o365-exchange-suspicious-mailbox-right-delegation.asciidoc index 6a213ab097..03ee023438 100644 --- a/docs/detections/prebuilt-rules/rule-details/o365-exchange-suspicious-mailbox-right-delegation.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/o365-exchange-suspicious-mailbox-right-delegation.asciidoc @@ -47,6 +47,14 @@ Identifies the assignment of rights to access content from another mailbox. An a ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/o365-mailbox-audit-logging-bypass.asciidoc b/docs/detections/prebuilt-rules/rule-details/o365-mailbox-audit-logging-bypass.asciidoc index f7971d947f..837eae48e7 100644 --- a/docs/detections/prebuilt-rules/rule-details/o365-mailbox-audit-logging-bypass.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/o365-mailbox-audit-logging-bypass.asciidoc @@ -48,6 +48,14 @@ Detects the occurrence of mailbox audit bypass associations. The mailbox audit i ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/okta-brute-force-or-password-spraying-attack.asciidoc b/docs/detections/prebuilt-rules/rule-details/okta-brute-force-or-password-spraying-attack.asciidoc index db01960064..5240b9e14c 100644 --- a/docs/detections/prebuilt-rules/rule-details/okta-brute-force-or-password-spraying-attack.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/okta-brute-force-or-password-spraying-attack.asciidoc @@ -76,6 +76,14 @@ This rule alerts when a high number of failed Okta user authentication attempts - Review and update your security policies based on the findings from the incident. ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/okta-fastpass-phishing-detection.asciidoc b/docs/detections/prebuilt-rules/rule-details/okta-fastpass-phishing-detection.asciidoc index 3099630b2a..ab9f6058ee 100644 --- a/docs/detections/prebuilt-rules/rule-details/okta-fastpass-phishing-detection.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/okta-fastpass-phishing-detection.asciidoc @@ -50,6 +50,18 @@ Detects when Okta FastPass prevents a user from authenticating to a phishing web ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +This rule requires Okta to have the following turned on: + +Okta Identity Engine - select 'Phishing Resistance for FastPass' under Settings > Features in the Admin Console. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/okta-sign-in-events-via-third-party-idp.asciidoc b/docs/detections/prebuilt-rules/rule-details/okta-sign-in-events-via-third-party-idp.asciidoc index 85c0224cea..3ed45c9ec3 100644 --- a/docs/detections/prebuilt-rules/rule-details/okta-sign-in-events-via-third-party-idp.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/okta-sign-in-events-via-third-party-idp.asciidoc @@ -84,6 +84,14 @@ Adversaries may attempt to add an unauthorized IdP to an Okta tenant to gain acc - If the deactivated IdP was crucial to the organization, consider adding a new IdP and removing the unauthorized IdP. ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/okta-threatinsight-threat-suspected-promotion.asciidoc b/docs/detections/prebuilt-rules/rule-details/okta-threatinsight-threat-suspected-promotion.asciidoc index 9d6c4a4cc9..257c210270 100644 --- a/docs/detections/prebuilt-rules/rule-details/okta-threatinsight-threat-suspected-promotion.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/okta-threatinsight-threat-suspected-promotion.asciidoc @@ -52,6 +52,14 @@ This is a promotion rule for Okta ThreatInsight suspected threat events, which a Consult vendor documentation on interpreting specific events. ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/okta-user-session-impersonation.asciidoc b/docs/detections/prebuilt-rules/rule-details/okta-user-session-impersonation.asciidoc index 160bb0288e..be07bd702c 100644 --- a/docs/detections/prebuilt-rules/rule-details/okta-user-session-impersonation.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/okta-user-session-impersonation.asciidoc @@ -74,6 +74,14 @@ The detection of an Okta User Session Impersonation indicates that a user has in - Implement additional monitoring and logging of Okta events to improve visibility of user actions. ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query 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 b3066cb682..f6dc76f940 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 @@ -51,6 +51,14 @@ Detects when a specific Okta actor has multiple sessions started from different ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/onedrive-malware-file-upload.asciidoc b/docs/detections/prebuilt-rules/rule-details/onedrive-malware-file-upload.asciidoc index 32c8337f39..99400f43f8 100644 --- a/docs/detections/prebuilt-rules/rule-details/onedrive-malware-file-upload.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/onedrive-malware-file-upload.asciidoc @@ -47,6 +47,14 @@ Identifies the occurence of files uploaded to OneDrive being detected as Malware ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/peripheral-device-discovery.asciidoc b/docs/detections/prebuilt-rules/rule-details/peripheral-device-discovery.asciidoc index 3b8e6aaec2..d497cb82f3 100644 --- a/docs/detections/prebuilt-rules/rule-details/peripheral-device-discovery.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/peripheral-device-discovery.asciidoc @@ -78,6 +78,20 @@ This rule looks for the execution of the `fsutil` utility with the `fsinfo` subc - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/persistence-via-bits-job-notify-cmdline.asciidoc b/docs/detections/prebuilt-rules/rule-details/persistence-via-bits-job-notify-cmdline.asciidoc index 376c216b23..742e97b145 100644 --- a/docs/detections/prebuilt-rules/rule-details/persistence-via-bits-job-notify-cmdline.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/persistence-via-bits-job-notify-cmdline.asciidoc @@ -47,6 +47,20 @@ An adversary can use the Background Intelligent Transfer Service (BITS) SetNotif *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/persistence-via-directoryservice-plugin-modification.asciidoc b/docs/detections/prebuilt-rules/rule-details/persistence-via-directoryservice-plugin-modification.asciidoc index 4264265666..b195e9ff45 100644 --- a/docs/detections/prebuilt-rules/rule-details/persistence-via-directoryservice-plugin-modification.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/persistence-via-directoryservice-plugin-modification.asciidoc @@ -40,6 +40,38 @@ Identifies the creation or modification of a DirectoryService PlugIns (dsplug) f *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### The following steps should be executed in order to add the Elastic Defend integration on a macOS 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, for MacOS it is recommended to select "Traditional Endpoints". +- 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/persistence-via-docker-shortcut-modification.asciidoc b/docs/detections/prebuilt-rules/rule-details/persistence-via-docker-shortcut-modification.asciidoc index 55b8f2a72c..883f1ddc35 100644 --- a/docs/detections/prebuilt-rules/rule-details/persistence-via-docker-shortcut-modification.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/persistence-via-docker-shortcut-modification.asciidoc @@ -40,6 +40,38 @@ An adversary can establish persistence by modifying an existing macOS dock prope *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### The following steps should be executed in order to add the Elastic Defend integration on a macOS 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, for MacOS it is recommended to select "Traditional Endpoints". +- 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/persistence-via-folder-action-script.asciidoc b/docs/detections/prebuilt-rules/rule-details/persistence-via-folder-action-script.asciidoc index fae5f8d3c5..6672adf382 100644 --- a/docs/detections/prebuilt-rules/rule-details/persistence-via-folder-action-script.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/persistence-via-folder-action-script.asciidoc @@ -41,6 +41,38 @@ Detects modification of a Folder Action script. A Folder Action script is execut *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### The following steps should be executed in order to add the Elastic Defend integration on a macOS 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, for MacOS it is recommended to select "Traditional Endpoints". +- 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/persistence-via-hidden-run-key-detected.asciidoc b/docs/detections/prebuilt-rules/rule-details/persistence-via-hidden-run-key-detected.asciidoc index f38ef6b84a..e6a3de9de8 100644 --- a/docs/detections/prebuilt-rules/rule-details/persistence-via-hidden-run-key-detected.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/persistence-via-hidden-run-key-detected.asciidoc @@ -47,6 +47,20 @@ Identifies a persistence mechanism that utilizes the NtSetValueKey native API to *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/persistence-via-kde-autostart-script-or-desktop-file-modification.asciidoc b/docs/detections/prebuilt-rules/rule-details/persistence-via-kde-autostart-script-or-desktop-file-modification.asciidoc index ddac0c54e9..1ec2762ca0 100644 --- a/docs/detections/prebuilt-rules/rule-details/persistence-via-kde-autostart-script-or-desktop-file-modification.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/persistence-via-kde-autostart-script-or-desktop-file-modification.asciidoc @@ -61,8 +61,8 @@ Adversaries may exploit this feature to maintain persistence on a compromised sy The detection rule 'Persistence via KDE AutoStart Script or Desktop File Modification' is designed to identify such activities by monitoring file events on Linux systems. It specifically targets the creation or modification of files with extensions ".sh" or ".desktop" in various AutoStart directories. By detecting these events, the rule helps security analysts identify potential abuse of KDE AutoStart functionality by malicious actors. > **Note**: -> This investigation guide uses the {security-guide}/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. -> This investigation guide uses {security-guide}/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. ### Possible investigation steps @@ -112,6 +112,53 @@ The detection rule 'Persistence via KDE AutoStart Script or Desktop File Modific - Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. - Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). +---------------------------------- + +==== Setup + + +[source, markdown] +---------------------------------- + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Auditbeat + +### 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. + +#### 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. +- 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. +- 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. + +### Auditbeat Setup +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + +#### The following steps should be executed in order to add the Auditbeat on a Linux System: +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html. + +#### Custom Ingest Pipeline +For versions <8.2, you need to add a custom ingest pipeline to populate `event.ingested` with @timestamp for non-elastic-agent indexes, like auditbeats/filebeat/winlogbeat etc. For more details to add a custom ingest pipeline refer to the https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html. + + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/persistence-via-login-or-logout-hook.asciidoc b/docs/detections/prebuilt-rules/rule-details/persistence-via-login-or-logout-hook.asciidoc index d3a51f8871..4cca79470b 100644 --- a/docs/detections/prebuilt-rules/rule-details/persistence-via-login-or-logout-hook.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/persistence-via-login-or-logout-hook.asciidoc @@ -41,6 +41,38 @@ Identifies use of the Defaults command to install a login or logoff hook in MacO *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### The following steps should be executed in order to add the Elastic Defend integration on a macOS 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, for MacOS it is recommended to select "Traditional Endpoints". +- 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/persistence-via-microsoft-office-addins.asciidoc b/docs/detections/prebuilt-rules/rule-details/persistence-via-microsoft-office-addins.asciidoc index ff55e87e67..e004fc4be5 100644 --- a/docs/detections/prebuilt-rules/rule-details/persistence-via-microsoft-office-addins.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/persistence-via-microsoft-office-addins.asciidoc @@ -44,6 +44,20 @@ Detects attempts to establish persistence on an endpoint by abusing Microsoft Of *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/persistence-via-microsoft-outlook-vba.asciidoc b/docs/detections/prebuilt-rules/rule-details/persistence-via-microsoft-outlook-vba.asciidoc index 12cf0291a7..d3db907cbe 100644 --- a/docs/detections/prebuilt-rules/rule-details/persistence-via-microsoft-outlook-vba.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/persistence-via-microsoft-outlook-vba.asciidoc @@ -45,6 +45,20 @@ Detects attempts to establish persistence on an endpoint by installing a rogue M *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/persistence-via-powershell-profile.asciidoc b/docs/detections/prebuilt-rules/rule-details/persistence-via-powershell-profile.asciidoc index 27199ad249..1242c4416a 100644 --- a/docs/detections/prebuilt-rules/rule-details/persistence-via-powershell-profile.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/persistence-via-powershell-profile.asciidoc @@ -60,7 +60,7 @@ PowerShell profiles are scripts executed when PowerShell starts, customizing the This rule identifies the creation or modification of a PowerShell profile. It does this by monitoring file events on Windows systems, specifically targeting profile-related file paths and names, such as `profile.ps1` and `Microsoft.Powershell_profile.ps1`. By detecting these activities, security analysts can investigate potential abuse of PowerShell profiles for malicious persistence. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. ### Possible investigation steps diff --git a/docs/detections/prebuilt-rules/rule-details/persistence-via-scheduled-job-creation.asciidoc b/docs/detections/prebuilt-rules/rule-details/persistence-via-scheduled-job-creation.asciidoc index 761238983c..537b72c6ae 100644 --- a/docs/detections/prebuilt-rules/rule-details/persistence-via-scheduled-job-creation.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/persistence-via-scheduled-job-creation.asciidoc @@ -42,6 +42,20 @@ A job can be used to schedule programs or scripts to be executed at a specified *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/persistence-via-telemetrycontroller-scheduled-task-hijack.asciidoc b/docs/detections/prebuilt-rules/rule-details/persistence-via-telemetrycontroller-scheduled-task-hijack.asciidoc index 7a313b8087..4c41e1631e 100644 --- a/docs/detections/prebuilt-rules/rule-details/persistence-via-telemetrycontroller-scheduled-task-hijack.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/persistence-via-telemetrycontroller-scheduled-task-hijack.asciidoc @@ -46,6 +46,20 @@ Detects the successful hijack of Microsoft Compatibility Appraiser scheduled tas *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/persistence-via-update-orchestrator-service-hijack.asciidoc b/docs/detections/prebuilt-rules/rule-details/persistence-via-update-orchestrator-service-hijack.asciidoc index a130319e7d..19b9aadcad 100644 --- a/docs/detections/prebuilt-rules/rule-details/persistence-via-update-orchestrator-service-hijack.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/persistence-via-update-orchestrator-service-hijack.asciidoc @@ -61,7 +61,7 @@ Windows Update Orchestrator Service is a DCOM service used by other components t This rule will detect uncommon processes spawned by `svchost.exe` with `UsoSvc` as the command line parameters. Attackers can leverage this technique to elevate privileges or maintain persistence. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps @@ -105,6 +105,20 @@ This rule will detect uncommon processes spawned by `svchost.exe` with `UsoSvc` - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/persistence-via-wmi-event-subscription.asciidoc b/docs/detections/prebuilt-rules/rule-details/persistence-via-wmi-event-subscription.asciidoc index 3cd7dc69fe..620c4a4913 100644 --- a/docs/detections/prebuilt-rules/rule-details/persistence-via-wmi-event-subscription.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/persistence-via-wmi-event-subscription.asciidoc @@ -46,6 +46,20 @@ An adversary can use Windows Management Instrumentation (WMI) to install event f *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/persistence-via-wmi-standard-registry-provider.asciidoc b/docs/detections/prebuilt-rules/rule-details/persistence-via-wmi-standard-registry-provider.asciidoc index 87c1272eee..50ef06d865 100644 --- a/docs/detections/prebuilt-rules/rule-details/persistence-via-wmi-standard-registry-provider.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/persistence-via-wmi-standard-registry-provider.asciidoc @@ -57,7 +57,7 @@ The Windows Management Instrumentation (WMI) StdRegProv is a registry provider t This rule identifies instances where the WMI StdRegProv is used to modify specific registry paths associated with persistence mechanisms. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. ### Possible investigation steps diff --git a/docs/detections/prebuilt-rules/rule-details/persistent-scripts-in-the-startup-directory.asciidoc b/docs/detections/prebuilt-rules/rule-details/persistent-scripts-in-the-startup-directory.asciidoc index 1e9287dd59..1eb98e48c8 100644 --- a/docs/detections/prebuilt-rules/rule-details/persistent-scripts-in-the-startup-directory.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/persistent-scripts-in-the-startup-directory.asciidoc @@ -57,7 +57,7 @@ The Windows Startup folder is a special folder in Windows. Programs added to thi This rule looks for shortcuts created by wscript.exe or cscript.exe, or js/vbs scripts created by any process. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps @@ -105,6 +105,20 @@ This rule looks for shortcuts created by wscript.exe or cscript.exe, or js/vbs s - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/port-forwarding-rule-addition.asciidoc b/docs/detections/prebuilt-rules/rule-details/port-forwarding-rule-addition.asciidoc index b75c1c75ae..b747030188 100644 --- a/docs/detections/prebuilt-rules/rule-details/port-forwarding-rule-addition.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/port-forwarding-rule-addition.asciidoc @@ -94,6 +94,20 @@ This rule monitors the modifications to the `HKLM\SYSTEM\*ControlSet*\Services\P +---------------------------------- + +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/possible-consent-grant-attack-via-azure-registered-application.asciidoc b/docs/detections/prebuilt-rules/rule-details/possible-consent-grant-attack-via-azure-registered-application.asciidoc index 1ec4714a0d..1273c097f9 100644 --- a/docs/detections/prebuilt-rules/rule-details/possible-consent-grant-attack-via-azure-registered-application.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/possible-consent-grant-attack-via-azure-registered-application.asciidoc @@ -56,7 +56,7 @@ Detects when a user grants permissions to an Azure-registered application or whe In an illicit consent grant attack, the attacker creates an Azure-registered application that requests access to data such as contact information, email, or documents. The attacker then tricks an end user into granting that application consent to access their data either through a phishing attack, or by injecting illicit code into a trusted website. After the illicit application has been granted consent, it has account-level access to data without the need for an organizational account. Normal remediation steps like resetting passwords for breached accounts or requiring multi-factor authentication (MFA) on accounts are not effective against this type of attack, since these are third-party applications and are external to the organization. -Official Microsoft guidance for detecting and remediating this attack can be found [here](https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/detect-and-remediate-illicit-consent-grants). +Official Microsoft guidance for detecting and remediating this attack can be found https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/detect-and-remediate-illicit-consent-grants. #### Possible investigation steps @@ -69,7 +69,7 @@ Official Microsoft guidance for detecting and remediating this attack can be fou - Low rating or score or bad comments. - Apps with a suspicious publisher or website. - Apps whose last update is not recent. This might indicate an app that is no longer supported. -- Export and examine the [Oauth app auditing](https://docs.microsoft.com/en-us/defender-cloud-apps/manage-app-permissions#oauth-app-auditing) to identify users affected. +- Export and examine the https://docs.microsoft.com/en-us/defender-cloud-apps/manage-app-permissions#oauth-app-auditing to identify users affected. ### False positive analysis @@ -87,15 +87,23 @@ Official Microsoft guidance for detecting and remediating this attack can be fou - Disable the malicious application to stop user access and the application access to your data. - Revoke the application Oauth consent grant. The `Remove-AzureADOAuth2PermissionGrant` cmdlet can be used to complete this task. - Remove the service principal application role assignment. The `Remove-AzureADServiceAppRoleAssignment` cmdlet can be used to complete this task. -- Revoke the refresh token for all users assigned to the application. Azure provides a [playbook](https://github.com/Azure/Azure-Sentinel/tree/master/Playbooks/Revoke-AADSignInSessions) for this task. -- [Report](https://docs.microsoft.com/en-us/defender-cloud-apps/manage-app-permissions#send-feedback) the application as malicious to Microsoft. +- Revoke the refresh token for all users assigned to the application. Azure provides a https://github.com/Azure/Azure-Sentinel/tree/master/Playbooks/Revoke-AADSignInSessions for this task. +- https://docs.microsoft.com/en-us/defender-cloud-apps/manage-app-permissions#send-feedback the application as malicious to Microsoft. - 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. - Investigate the potential for data compromise from the user's email and file sharing services. Activate your Data Loss incident response playbook. - Disable the permission for a user to set consent permission on their behalf. - - Enable the [Admin consent request](https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/configure-admin-consent-workflow) feature. + - Enable the https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/configure-admin-consent-workflow feature. - 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 + + +[source, markdown] +---------------------------------- +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/possible-okta-dos-attack.asciidoc b/docs/detections/prebuilt-rules/rule-details/possible-okta-dos-attack.asciidoc index 79def4629f..6150d912df 100644 --- a/docs/detections/prebuilt-rules/rule-details/possible-okta-dos-attack.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/possible-okta-dos-attack.asciidoc @@ -49,6 +49,14 @@ Detects possible Denial of Service (DoS) attacks against an Okta organization. A ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-admin-group-account-addition.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-admin-group-account-addition.asciidoc index c58963f440..2d7305015c 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-admin-group-account-addition.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-admin-group-account-addition.asciidoc @@ -40,6 +40,38 @@ Identifies attempts to add an account to the admin group via the command line. T *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### The following steps should be executed in order to add the Elastic Defend integration on a macOS 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, for MacOS it is recommended to select "Traditional Endpoints". +- 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-antimalware-scan-interface-bypass-via-powershell.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-antimalware-scan-interface-bypass-via-powershell.asciidoc index 30f27dbbdd..f4789d0f7b 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-antimalware-scan-interface-bypass-via-powershell.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-antimalware-scan-interface-bypass-via-powershell.asciidoc @@ -58,7 +58,7 @@ The Windows Antimalware Scan Interface (AMSI) is a versatile interface standard This rule identifies scripts that contain methods and classes that can be abused to bypass AMSI. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps diff --git a/docs/detections/prebuilt-rules/rule-details/potential-application-shimming-via-sdbinst.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-application-shimming-via-sdbinst.asciidoc index 9f67596e95..8ef2f48e19 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-application-shimming-via-sdbinst.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-application-shimming-via-sdbinst.asciidoc @@ -43,6 +43,20 @@ The Application Shim was created to allow for backward compatibility of software *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-buffer-overflow-attack-detected.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-buffer-overflow-attack-detected.asciidoc index ec8f18e92a..e0405e1e2b 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-buffer-overflow-attack-detected.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-buffer-overflow-attack-detected.asciidoc @@ -40,6 +40,21 @@ Detects potential buffer overflow attacks by querying the "Segfault Detected" pr *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +This rule leverages alert data from other prebuilt detection rules to function correctly. + +### Dependent Elastic Detection Rule Enablement +As a higher-order rule (based on other detections), this rule also requires the following prerequisite Elastic detection rule to be installed and enabled: +- Segfault Detected (5c81fc9d-1eae-437f-ba07-268472967013) + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-chroot-container-escape-via-mount.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-chroot-container-escape-via-mount.asciidoc index 6d99b91241..d0526d6126 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-chroot-container-escape-via-mount.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-chroot-container-escape-via-mount.asciidoc @@ -41,6 +41,47 @@ Monitors for the execution of a file system mount followed by a chroot execution *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + +Session View uses process data collected by the Elastic Defend integration, but this data is not always collected by default. Session View is available on enterprise subscription for versions 8.3 and above. +#### To confirm that Session View data is enabled: +- Go to “Manage → Policies”, and edit one or more of your Elastic Defend integration policies. +- Select the” Policy settings” tab, then scroll down to the “Linux event collection” section near the bottom. +- Check the box for “Process events”, and turn on the “Include session data” toggle. +- If you want to include file and network alerts in Session View, check the boxes for “Network and File events”. +- If you want to enable terminal output capture, turn on the “Capture terminal output” toggle. +For more information about the additional fields collected when this setting is enabled and the usage of Session View for Analysis refer to the https://www.elastic.co/guide/en/security/current/session-view.html. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-code-execution-via-postgresql.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-code-execution-via-postgresql.asciidoc index 92a94c542f..f9316ff8ba 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-code-execution-via-postgresql.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-code-execution-via-postgresql.asciidoc @@ -40,6 +40,38 @@ This rule monitors for suspicious activities that may indicate an attacker attem *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-cookies-theft-via-browser-debugging.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-cookies-theft-via-browser-debugging.asciidoc index 4881d58e95..76030ebf6a 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-cookies-theft-via-browser-debugging.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-cookies-theft-via-browser-debugging.asciidoc @@ -48,6 +48,20 @@ Identifies the execution of a Chromium based browser with the debugging process *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-credential-access-via-dcsync.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-credential-access-via-dcsync.asciidoc index d8de725d0b..48af2f1742 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-credential-access-via-dcsync.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-credential-access-via-dcsync.asciidoc @@ -65,9 +65,9 @@ Active Directory data consists of objects that have properties, or attributes. E Adversaries can use the DCSync technique that uses Windows Domain Controller's API to simulate the replication process from a remote domain controller, compromising major credential material such as the Kerberos krbtgt keys used legitimately for tickets creation, but also tickets forging by attackers. This attack requires some extended privileges to succeed (DS-Replication-Get-Changes and DS-Replication-Get-Changes-All), which are granted by default to members of the Administrators, Domain Admins, Enterprise Admins, and Domain Controllers groups. Privileged accounts can be abused to grant controlled objects the right to DCsync/Replicate. -More details can be found on [Threat Hunter Playbook](https://threathunterplaybook.com/library/windows/active_directory_replication.html?highlight=dcsync#directory-replication-services-auditing) and [The Hacker Recipes](https://www.thehacker.recipes/ad/movement/credentials/dumping/dcsync). +More details can be found on https://threathunterplaybook.com/library/windows/active_directory_replication.html?highlight=dcsync#directory-replication-services-auditing and https://www.thehacker.recipes/ad/movement/credentials/dumping/dcsync. -This rule monitors for Event ID 4662 (Operation was performed on an Active Directory object) and identifies events that use the access mask 0x100 (Control Access) and properties that contain at least one of the following or their equivalent Schema-Id-GUID (DS-Replication-Get-Changes, DS-Replication-Get-Changes-All, DS-Replication-Get-Changes-In-Filtered-Set). It also filters out events that use computer accounts and also Azure AD Connect MSOL accounts (more details [here](https://techcommunity.microsoft.com/t5/microsoft-defender-for-identity/ad-connect-msol-user-suspected-dcsync-attack/m-p/788028)). +This rule monitors for Event ID 4662 (Operation was performed on an Active Directory object) and identifies events that use the access mask 0x100 (Control Access) and properties that contain at least one of the following or their equivalent Schema-Id-GUID (DS-Replication-Get-Changes, DS-Replication-Get-Changes-All, DS-Replication-Get-Changes-In-Filtered-Set). It also filters out events that use computer accounts and also Azure AD Connect MSOL accounts (more details https://techcommunity.microsoft.com/t5/microsoft-defender-for-identity/ad-connect-msol-user-suspected-dcsync-attack/m-p/788028). #### Possible investigation steps @@ -93,6 +93,28 @@ This rule monitors for Event ID 4662 (Operation was performed on an Active Direc - 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 + + +[source, markdown] +---------------------------------- + +The 'Audit Directory Service Access' 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 Access (Success,Failure) +``` + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-credential-access-via-duplicatehandle-in-lsass.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-credential-access-via-duplicatehandle-in-lsass.asciidoc index 6a9886eb31..5b09a3ef92 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-credential-access-via-duplicatehandle-in-lsass.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-credential-access-via-duplicatehandle-in-lsass.asciidoc @@ -41,6 +41,20 @@ Identifies suspicious access to an LSASS handle via DuplicateHandle from an unkn *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-credential-access-via-lsass-memory-dump.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-credential-access-via-lsass-memory-dump.asciidoc index 7ccb3e4cd3..af64c7fb61 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-credential-access-via-lsass-memory-dump.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-credential-access-via-lsass-memory-dump.asciidoc @@ -43,6 +43,20 @@ Identifies suspicious access to LSASS handle from a call trace pointing to DBGHe *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-credential-access-via-renamed-com-services-dll.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-credential-access-via-renamed-com-services-dll.asciidoc index ba3022621e..bac93ce1e9 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-credential-access-via-renamed-com-services-dll.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-credential-access-via-renamed-com-services-dll.asciidoc @@ -56,7 +56,7 @@ COMSVCS.DLL is a Windows library that exports the MiniDump function, which can b This rule identifies suspicious instances of rundll32.exe loading a renamed COMSVCS.DLL image, which can indicate potential abuse of the MiniDump function for credential theft. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. ### Possible investigation steps @@ -111,6 +111,17 @@ This rule identifies suspicious instances of rundll32.exe loading a renamed COMS ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- + +You will need to enable logging of ImageLoads in your Sysmon configuration to include COMSVCS.DLL by Imphash or Original +File Name. + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-credential-access-via-trusted-developer-utility.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-credential-access-via-trusted-developer-utility.asciidoc index 8b53911a47..c14d111159 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-credential-access-via-trusted-developer-utility.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-credential-access-via-trusted-developer-utility.asciidoc @@ -58,7 +58,7 @@ Adversaries can abuse MSBuild to proxy the execution of malicious code. The inli This rule looks for the MSBuild process loading `vaultcli.dll` or `SAMLib.DLL`, which indicates the execution of credential access activities. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps diff --git a/docs/detections/prebuilt-rules/rule-details/potential-credential-access-via-windows-utilities.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-credential-access-via-windows-utilities.asciidoc index fd8c681398..0cc38a9609 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-credential-access-via-windows-utilities.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-credential-access-via-windows-utilities.asciidoc @@ -87,6 +87,20 @@ This rule looks for the execution of utilities that can extract credential data - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-curl-cve-2023-38545-exploitation.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-curl-cve-2023-38545-exploitation.asciidoc index 2f6706b156..a99b7945d6 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-curl-cve-2023-38545-exploitation.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-curl-cve-2023-38545-exploitation.asciidoc @@ -43,6 +43,51 @@ Detects potential exploitation of curl CVE-2023-38545 by monitoring for vulnerab *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + +Elastic Defend integration does not collect environment variable logging by default. +In order to capture this behavior, this rule requires a specific configuration option set within the advanced settings of the Elastic Defend integration. + #### To set up environment variable capture for an Elastic Agent policy: +- Go to “Security → Manage → Policies”. +- Select an “Elastic Agent policy”. +- Click “Show advanced settings”. +- Scroll down or search for “linux.advanced.capture_env_vars”. +- Enter the names of environment variables you want to capture, separated by commas. +- For this rule the linux.advanced.capture_env_vars variable should be set to "http_proxy,HTTPS_PROXY,ALL_PROXY". +- Click “Save”. +After saving the integration change, the Elastic Agents running this policy will be updated and the rule will function properly. +For more information on capturing environment variables refer to the https://www.elastic.co/guide/en/security/current/environment-variable-capture.html. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-data-exfiltration-activity-to-an-unusual-destination-port.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-data-exfiltration-activity-to-an-unusual-destination-port.asciidoc index f816520a70..445e1cf5ac 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-data-exfiltration-activity-to-an-unusual-destination-port.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-data-exfiltration-activity-to-an-unusual-destination-port.asciidoc @@ -39,6 +39,37 @@ A machine learning job has detected data exfiltration to a particular destinatio *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- +The rule requires the Data Exfiltration Detection integration assets to be installed, as well as network and file events collected by integrations such as Elastic Defend and Network Packet Capture (for network events only). + +### Data Exfiltration Detection Setup +The Data Exfiltration Detection integration detects data exfiltration activity by identifying abnormalities in network and file events. Anomalies are detected using Elastic's Anomaly Detection feature. + +#### Prerequisite Requirements: +- Fleet is required for Data Exfiltration Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html. +- Network events collected by the https://docs.elastic.co/en/integrations/endpoint or https://docs.elastic.co/integrations/network_traffic integration. +- To install Elastic Defend, refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html. +- To add the Network Packet Capture integration to an Elastic Agent policy, refer to https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html guide. + +#### The following steps should be executed to install assets associated with the Data Exfiltration Detection integration: +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Data Exfiltration Detection and select the integration to see more details about it. +- Under Settings, click Install Data Exfiltration Detection assets and follow the prompts to install the assets. + +#### Anomaly Detection Setup +Before you can enable rules for Data Exfiltration Detection, you'll need to enable the corresponding Anomaly Detection jobs. +- Go to the Kibana homepage. Under Analytics, click Machine Learning. +- Under Anomaly Detection, click Jobs, and then click "Create job". Select the Data View containing your network data. For example, this would be `logs-endpoint.events.*` if you used Elastic Defend to collect events, or `logs-network_traffic.*` if you used Network Packet Capture. +- If the selected Data View contains events that match the query in https://github.com/elastic/integrations/blob/main/packages/ded/kibana/ml_module/ded-ml.json configuration file, you will see a card for Data Exfiltration Detection under "Use preconfigured jobs". +- Keep the default settings and click "Create jobs" to start the anomaly detection jobs and datafeeds. + +---------------------------------- + *Framework*: MITRE ATT&CK^TM^ * Tactic: diff --git a/docs/detections/prebuilt-rules/rule-details/potential-data-exfiltration-activity-to-an-unusual-ip-address.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-data-exfiltration-activity-to-an-unusual-ip-address.asciidoc index 3400bd189f..4e2813a4af 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-data-exfiltration-activity-to-an-unusual-ip-address.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-data-exfiltration-activity-to-an-unusual-ip-address.asciidoc @@ -39,6 +39,37 @@ A machine learning job has detected data exfiltration to a particular geo-locati *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- +The rule requires the Data Exfiltration Detection integration assets to be installed, as well as network and file events collected by integrations such as Elastic Defend and Network Packet Capture (for network events only). + +### Data Exfiltration Detection Setup +The Data Exfiltration Detection integration detects data exfiltration activity by identifying abnormalities in network and file events. Anomalies are detected using Elastic's Anomaly Detection feature. + +#### Prerequisite Requirements: +- Fleet is required for Data Exfiltration Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html. +- Network events collected by the https://docs.elastic.co/en/integrations/endpoint or https://docs.elastic.co/integrations/network_traffic integration. +- To install Elastic Defend, refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html. +- To add the Network Packet Capture integration to an Elastic Agent policy, refer to https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html guide. + +#### The following steps should be executed to install assets associated with the Data Exfiltration Detection integration: +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Data Exfiltration Detection and select the integration to see more details about it. +- Under Settings, click Install Data Exfiltration Detection assets and follow the prompts to install the assets. + +#### Anomaly Detection Setup +Before you can enable rules for Data Exfiltration Detection, you'll need to enable the corresponding Anomaly Detection jobs. +- Go to the Kibana homepage. Under Analytics, click Machine Learning. +- Under Anomaly Detection, click Jobs, and then click "Create job". Select the Data View containing your network data. For example, this would be `logs-endpoint.events.*` if you used Elastic Defend to collect events, or `logs-network_traffic.*` if you used Network Packet Capture. +- If the selected Data View contains events that match the query in https://github.com/elastic/integrations/blob/main/packages/ded/kibana/ml_module/ded-ml.json configuration file, you will see a card for Data Exfiltration Detection under "Use preconfigured jobs". +- Keep the default settings and click "Create jobs" to start the anomaly detection jobs and datafeeds. + +---------------------------------- + *Framework*: MITRE ATT&CK^TM^ * Tactic: diff --git a/docs/detections/prebuilt-rules/rule-details/potential-data-exfiltration-activity-to-an-unusual-iso-code.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-data-exfiltration-activity-to-an-unusual-iso-code.asciidoc index ac9f50c20c..2f5ca1a38d 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-data-exfiltration-activity-to-an-unusual-iso-code.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-data-exfiltration-activity-to-an-unusual-iso-code.asciidoc @@ -39,6 +39,37 @@ A machine learning job has detected data exfiltration to a particular geo-locati *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- +The rule requires the Data Exfiltration Detection integration assets to be installed, as well as network and file events collected by integrations such as Elastic Defend and Network Packet Capture (for network events only). + +### Data Exfiltration Detection Setup +The Data Exfiltration Detection integration detects data exfiltration activity by identifying abnormalities in network and file events. Anomalies are detected using Elastic's Anomaly Detection feature. + +#### Prerequisite Requirements: +- Fleet is required for Data Exfiltration Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html. +- Network events collected by the https://docs.elastic.co/en/integrations/endpoint or https://docs.elastic.co/integrations/network_traffic integration. +- To install Elastic Defend, refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html. +- To add the Network Packet Capture integration to an Elastic Agent policy, refer to https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html guide. + +#### The following steps should be executed to install assets associated with the Data Exfiltration Detection integration: +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Data Exfiltration Detection and select the integration to see more details about it. +- Under Settings, click Install Data Exfiltration Detection assets and follow the prompts to install the assets. + +#### Anomaly Detection Setup +Before you can enable rules for Data Exfiltration Detection, you'll need to enable the corresponding Anomaly Detection jobs. +- Go to the Kibana homepage. Under Analytics, click Machine Learning. +- Under Anomaly Detection, click Jobs, and then click "Create job". Select the Data View containing your network data. For example, this would be `logs-endpoint.events.*` if you used Elastic Defend to collect events, or `logs-network_traffic.*` if you used Network Packet Capture. +- If the selected Data View contains events that match the query in https://github.com/elastic/integrations/blob/main/packages/ded/kibana/ml_module/ded-ml.json configuration file, you will see a card for Data Exfiltration Detection under "Use preconfigured jobs". +- Keep the default settings and click "Create jobs" to start the anomaly detection jobs and datafeeds. + +---------------------------------- + *Framework*: MITRE ATT&CK^TM^ * Tactic: diff --git a/docs/detections/prebuilt-rules/rule-details/potential-data-exfiltration-activity-to-an-unusual-region.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-data-exfiltration-activity-to-an-unusual-region.asciidoc index 782cebb837..fdbd8db57b 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-data-exfiltration-activity-to-an-unusual-region.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-data-exfiltration-activity-to-an-unusual-region.asciidoc @@ -39,6 +39,37 @@ A machine learning job has detected data exfiltration to a particular geo-locati *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- +The rule requires the Data Exfiltration Detection integration assets to be installed, as well as network and file events collected by integrations such as Elastic Defend and Network Packet Capture (for network events only). + +### Data Exfiltration Detection Setup +The Data Exfiltration Detection integration detects data exfiltration activity by identifying abnormalities in network and file events. Anomalies are detected using Elastic's Anomaly Detection feature. + +#### Prerequisite Requirements: +- Fleet is required for Data Exfiltration Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html. +- Network events collected by the https://docs.elastic.co/en/integrations/endpoint or https://docs.elastic.co/integrations/network_traffic integration. +- To install Elastic Defend, refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html. +- To add the Network Packet Capture integration to an Elastic Agent policy, refer to https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html guide. + +#### The following steps should be executed to install assets associated with the Data Exfiltration Detection integration: +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Data Exfiltration Detection and select the integration to see more details about it. +- Under Settings, click Install Data Exfiltration Detection assets and follow the prompts to install the assets. + +#### Anomaly Detection Setup +Before you can enable rules for Data Exfiltration Detection, you'll need to enable the corresponding Anomaly Detection jobs. +- Go to the Kibana homepage. Under Analytics, click Machine Learning. +- Under Anomaly Detection, click Jobs, and then click "Create job". Select the Data View containing your network data. For example, this would be `logs-endpoint.events.*` if you used Elastic Defend to collect events, or `logs-network_traffic.*` if you used Network Packet Capture. +- If the selected Data View contains events that match the query in https://github.com/elastic/integrations/blob/main/packages/ded/kibana/ml_module/ded-ml.json configuration file, you will see a card for Data Exfiltration Detection under "Use preconfigured jobs". +- Keep the default settings and click "Create jobs" to start the anomaly detection jobs and datafeeds. + +---------------------------------- + *Framework*: MITRE ATT&CK^TM^ * Tactic: diff --git a/docs/detections/prebuilt-rules/rule-details/potential-defense-evasion-via-proot.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-defense-evasion-via-proot.asciidoc index 49bd7b73ac..fe04eaec9f 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-defense-evasion-via-proot.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-defense-evasion-via-proot.asciidoc @@ -40,6 +40,38 @@ Identifies the execution of the PRoot utility, an open-source tool for user-spac *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-dga-activity.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-dga-activity.asciidoc index e726c5c6d8..7594a3b4bd 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-dga-activity.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-dga-activity.asciidoc @@ -39,6 +39,64 @@ A population analysis machine learning job detected potential DGA (domain genera *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- +The rule requires the Domain Generation Algorithm (DGA) Detection integration assets to be installed, as well as DNS events collected by integrations such as Elastic Defend, Network Packet Capture, or Packetbeat. + +### DGA Detection Setup +The DGA Detection integration consists of an ML-based framework to detect DGA activity in DNS events. + +#### Prerequisite Requirements: +- Fleet is required for DGA Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html. +- DNS events collected by the https://docs.elastic.co/en/integrations/endpoint, https://docs.elastic.co/integrations/network_traffic integration, or https://www.elastic.co/guide/en/beats/packetbeat/current/packetbeat-overview.html. +- To install Elastic Defend, refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html. +- To add the Network Packet Capture integration to an Elastic Agent policy, refer to https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html guide. +- To set up and run Packetbeat, follow https://www.elastic.co/guide/en/beats/packetbeat/current/setting-up-and-running.html guide. + +#### The following steps should be executed to install assets associated with the DGA Detection integration: +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Domain Generation Algorithm Detection and select the integration to see more details about it. +- Under Settings, click Install Domain Generation Algorithm Detection assets and follow the prompts to install the assets. + +#### Ingest Pipeline Setup +Before you can enable this rule, you'll need to enrich DNS events with predictions from the Supervised DGA Detection model. This is done via the ingest pipeline named `-ml_dga_ingest_pipeline` installed with the DGA Detection package. +- If using an Elastic Beat such as Packetbeat, add the DGA ingest pipeline to it by adding a simple configuration https://www.elastic.co/guide/en/elasticsearch/reference/current/ingest.html#pipelines-for-beats to `packetbeat.yml`. +- If adding the DGA ingest pipeline to an existing pipeline, use a https://www.elastic.co/guide/en/elasticsearch/reference/current/pipeline-processor.html. + +#### Adding Custom Mappings +- Go to the Kibana homepage. Under Management, click Stack Management. +- Under Data click Index Management and navigate to the Component Templates tab. +- Templates that can be edited to add custom components will be marked with a @custom suffix. Edit the @custom component template corresponding to the beat/integration you added the DGA ingest pipeline to, by pasting the following JSON blob in the "Load JSON" flyout: +``` +{ + "properties": { + "ml_is_dga": { + "properties": { + "malicious_prediction": { + "type": "long" + }, + "malicious_probability": { + "type": "float" + } + } + } + } +} +``` + +### Anomaly Detection Setup +Before you can enable this rule, you'll need to enable the corresponding Anomaly Detection job. +- Go to the Kibana homepage. Under Analytics, click Machine Learning. +- Under Anomaly Detection, click Jobs, and then click "Create job". Select the Data View containing your enriched DNS events. For example, this would be `logs-endpoint.events.*` if you used Elastic Defend to collect events, or `logs-network_traffic.*` if you used Network Packet Capture. +- If the selected Data View contains events that match the query in https://github.com/elastic/integrations/blob/main/packages/dga/kibana/ml_module/dga-ml.json configuration file, you will see a card for DGA under "Use preconfigured jobs". +- Keep the default settings and click "Create jobs" to start the anomaly detection job and datafeed. + +---------------------------------- + *Framework*: MITRE ATT&CK^TM^ * Tactic: diff --git a/docs/detections/prebuilt-rules/rule-details/potential-disabling-of-apparmor.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-disabling-of-apparmor.asciidoc index 83b4abdc77..ea9e8c6604 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-disabling-of-apparmor.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-disabling-of-apparmor.asciidoc @@ -38,6 +38,38 @@ This rule monitors for potential attempts to disable AppArmor. AppArmor is a Lin *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-disabling-of-selinux.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-disabling-of-selinux.asciidoc index 2e14442197..c3f97cac61 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-disabling-of-selinux.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-disabling-of-selinux.asciidoc @@ -41,6 +41,50 @@ Identifies potential attempts to disable Security-Enhanced Linux (SELinux), whic *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Auditbeat + +### 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. + +#### 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. +- 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. +- 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. + +### Auditbeat Setup +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + +#### The following steps should be executed in order to add the Auditbeat on a Linux System: +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-dll-side-loading-via-microsoft-antimalware-service-executable.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-dll-side-loading-via-microsoft-antimalware-service-executable.asciidoc index 9cc9115b84..51e23b0d10 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-dll-side-loading-via-microsoft-antimalware-service-executable.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-dll-side-loading-via-microsoft-antimalware-service-executable.asciidoc @@ -46,6 +46,20 @@ Identifies a Windows trusted program that is known to be vulnerable to DLL Searc *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-dll-side-loading-via-trusted-microsoft-programs.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-dll-side-loading-via-trusted-microsoft-programs.asciidoc index 2f27cb30f2..74f4514371 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-dll-side-loading-via-trusted-microsoft-programs.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-dll-side-loading-via-trusted-microsoft-programs.asciidoc @@ -43,6 +43,20 @@ Identifies an instance of a Windows trusted program that is known to be vulnerab *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-dns-tunneling-via-nslookup.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-dns-tunneling-via-nslookup.asciidoc index 48cc438bd7..cf235bf400 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-dns-tunneling-via-nslookup.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-dns-tunneling-via-nslookup.asciidoc @@ -59,7 +59,7 @@ Attackers can abuse existing network rules that allow DNS communication with ext DNS queries can be used to infiltrate data such as commands to be run, malicious files, etc., and also for exfiltration, since queries can be used to send data to the attacker-controlled DNS server. This process is commonly known as DNS tunneling. -More information on how tunneling works and how it can be abused can be found on [Palo Alto Unit42 Research](https://unit42.paloaltonetworks.com/dns-tunneling-how-dns-can-be-abused-by-malicious-actors). +More information on how tunneling works and how it can be abused can be found on https://unit42.paloaltonetworks.com/dns-tunneling-how-dns-can-be-abused-by-malicious-actors. #### Possible investigation steps diff --git a/docs/detections/prebuilt-rules/rule-details/potential-evasion-via-filter-manager.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-evasion-via-filter-manager.asciidoc index 52263edc49..c9c99ae11d 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-evasion-via-filter-manager.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-evasion-via-filter-manager.asciidoc @@ -59,13 +59,13 @@ Attackers may try to unload minifilters to avoid protections such as malware det This rule identifies the attempt to unload a minifilter using the `fltmc.exe` command-line utility, a tool used to manage and query the filter drivers loaded on Windows systems. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps - Identify the user account that performed the action and whether it should perform this kind of action. - Examine the command line event to identify the target driver. - - Identify the minifilter's role in the environment and if it is security-related. Microsoft provides a [list](https://learn.microsoft.com/en-us/windows-hardware/drivers/ifs/allocated-altitudes) of allocated altitudes that may provide more context, such as the manufacturer. + - Identify the minifilter's role in the environment and if it is security-related. Microsoft provides a https://learn.microsoft.com/en-us/windows-hardware/drivers/ifs/allocated-altitudes of allocated altitudes that may provide more context, such as the manufacturer. - Contact the account owner and confirm whether they are aware of this activity. - 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. - Investigate other alerts associated with the user/host during the past 48 hours. diff --git a/docs/detections/prebuilt-rules/rule-details/potential-evasion-via-windows-filtering-platform.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-evasion-via-windows-filtering-platform.asciidoc index 0d5233737a..4172ccf3b4 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-evasion-via-windows-filtering-platform.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-evasion-via-windows-filtering-platform.asciidoc @@ -46,6 +46,28 @@ Identifies multiple Windows Filtering Platform block events and where the proces *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +The 'Filtering Platform Connection' 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 > +Object Access > +Filtering Platform Connection (Success,Failure) +``` + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-external-linux-ssh-brute-force-detected.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-external-linux-ssh-brute-force-detected.asciidoc index 64ac35f4a5..7a24b164b5 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-external-linux-ssh-brute-force-detected.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-external-linux-ssh-brute-force-detected.asciidoc @@ -80,6 +80,33 @@ In case this rule generates too much noise and external brute forcing is of not - 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 + + +[source, markdown] +---------------------------------- + +This rule requires data coming in from Filebeat. + +### Filebeat Setup +Filebeat is a lightweight shipper for forwarding and centralizing log data. Installed as an agent on your servers, Filebeat monitors the log files or locations that you specify, collects log events, and forwards them either to Elasticsearch or Logstash for indexing. + +#### The following steps should be executed in order to add the Filebeat on a Linux System: +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/filebeat/current/setup-repositories.html. +- To run Filebeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/running-on-docker.html. +- To run Filebeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/running-on-kubernetes.html. +- For quick start information for Filebeat refer to the https://www.elastic.co/guide/en/beats/filebeat/8.11/filebeat-installation-configuration.html. +- For complete “Setup and Run Filebeat” information refer to the https://www.elastic.co/guide/en/beats/filebeat/current/setting-up-and-running.html. + +#### Rule Specific Setup Note +- This rule requires the “Filebeat System Module” to be enabled. +- The system module collects and parses logs created by the system logging service of common Unix/Linux based distributions. +- To run the system module of Filebeat on Linux follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-system.html. + + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-file-transfer-via-certreq.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-file-transfer-via-certreq.asciidoc index fb157de9e9..cca49b4f9d 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-file-transfer-via-certreq.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-file-transfer-via-certreq.asciidoc @@ -61,7 +61,7 @@ Certreq is a command-line utility in Windows operating systems that allows users This rule identifies the potential abuse of Certreq to download files or upload data to a remote URL. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps diff --git a/docs/detections/prebuilt-rules/rule-details/potential-hidden-local-user-account-creation.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-hidden-local-user-account-creation.asciidoc index 438579ef8a..5b27c8436d 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-hidden-local-user-account-creation.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-hidden-local-user-account-creation.asciidoc @@ -40,6 +40,38 @@ Identifies attempts to create a local account that will be hidden from the macOS *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### The following steps should be executed in order to add the Elastic Defend integration on a macOS 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, for MacOS it is recommended to select "Traditional Endpoints". +- 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-hidden-process-via-mount-hidepid.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-hidden-process-via-mount-hidepid.asciidoc index f30a0efcaf..8fc96cac81 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-hidden-process-via-mount-hidepid.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-hidden-process-via-mount-hidepid.asciidoc @@ -40,6 +40,38 @@ Identifies the execution of mount process with hidepid parameter, which can make *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-internal-linux-ssh-brute-force-detected.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-internal-linux-ssh-brute-force-detected.asciidoc index 45b4aa4390..d9a400dc15 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-internal-linux-ssh-brute-force-detected.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-internal-linux-ssh-brute-force-detected.asciidoc @@ -76,6 +76,33 @@ The rule identifies consecutive internal SSH login failures targeting a user acc - 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 + + +[source, markdown] +---------------------------------- + +This rule requires data coming in from Filebeat. + +### Filebeat Setup +Filebeat is a lightweight shipper for forwarding and centralizing log data. Installed as an agent on your servers, Filebeat monitors the log files or locations that you specify, collects log events, and forwards them either to Elasticsearch or Logstash for indexing. + +#### The following steps should be executed in order to add the Filebeat on a Linux System: +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/filebeat/current/setup-repositories.html. +- To run Filebeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/running-on-docker.html. +- To run Filebeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/running-on-kubernetes.html. +- For quick start information for Filebeat refer to the https://www.elastic.co/guide/en/beats/filebeat/8.11/filebeat-installation-configuration.html. +- For complete “Setup and Run Filebeat” information refer to the https://www.elastic.co/guide/en/beats/filebeat/current/setting-up-and-running.html. + +#### Rule Specific Setup Note +- This rule requires the “Filebeat System Module” to be enabled. +- The system module collects and parses logs created by the system logging service of common Unix/Linux based distributions. +- To run the system module of Filebeat on Linux follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-system.html. + + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-invoke-mimikatz-powershell-script.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-invoke-mimikatz-powershell-script.asciidoc index be9812e4a6..6ae3a284a8 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-invoke-mimikatz-powershell-script.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-invoke-mimikatz-powershell-script.asciidoc @@ -53,11 +53,11 @@ Mimikatz is a credential dumper capable of obtaining plaintext Windows account l ### Investigating Mimikatz PowerShell Activity -[Mimikatz](https://github.com/gentilkiwi/mimikatz) is an open-source tool used to collect, decrypt, and/or use cached credentials. This tool is commonly abused by adversaries during the post-compromise stage where adversaries have gained an initial foothold on an endpoint and are looking to elevate privileges and seek out additional authentication objects such as tokens/hashes/credentials that can then be used to move laterally and pivot across a network. +https://github.com/gentilkiwi/mimikatz is an open-source tool used to collect, decrypt, and/or use cached credentials. This tool is commonly abused by adversaries during the post-compromise stage where adversaries have gained an initial foothold on an endpoint and are looking to elevate privileges and seek out additional authentication objects such as tokens/hashes/credentials that can then be used to move laterally and pivot across a network. This rule looks for PowerShell scripts that load mimikatz in memory, like Invoke-Mimikataz, which are used to dump credentials from the Local Security Authority Subsystem Service (LSASS). Any activity triggered from this rule should be treated with high priority as it typically represents an active adversary. -More information about Mimikatz components and how to detect/prevent them can be found on [ADSecurity](https://adsecurity.org/?page_id=1821). +More information about Mimikatz components and how to detect/prevent them can be found on https://adsecurity.org/?page_id=1821. #### Possible investigation steps @@ -96,6 +96,31 @@ More information about Mimikatz components and how to detect/prevent them can be - 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 + + +[source, markdown] +---------------------------------- + +The 'PowerShell Script Block Logging' logging policy must be configured (Enable). + +Steps to implement the logging policy with with Advanced Audit Configuration: + +``` +Computer Configuration > +Administrative Templates > +Windows PowerShell > +Turn on PowerShell Script Block Logging (Enable) +``` + +Steps to implement the logging policy via registry: + +``` +reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1 +``` + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-kerberos-attack-via-bifrost.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-kerberos-attack-via-bifrost.asciidoc index fcc7871277..2fccc21c37 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-kerberos-attack-via-bifrost.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-kerberos-attack-via-bifrost.asciidoc @@ -41,6 +41,38 @@ Identifies use of Bifrost, a known macOS Kerberos pentesting tool, which can be *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### The following steps should be executed in order to add the Elastic Defend integration on a macOS 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, for MacOS it is recommended to select "Traditional Endpoints". +- 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-linux-backdoor-user-account-creation.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-linux-backdoor-user-account-creation.asciidoc index 03e0b52540..ca491a38e8 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-linux-backdoor-user-account-creation.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-linux-backdoor-user-account-creation.asciidoc @@ -57,8 +57,8 @@ Attackers may create new accounts with a UID of 0 to maintain root access to tar This rule identifies the usage of the `usermod` command to set a user's UID to 0, indicating that the user becomes a root account. > **Note**: -> This investigation guide uses the {security-guide}/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. -> This investigation guide uses {security-guide}/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. #### Possible investigation steps - Investigate the user account that got assigned a uid of 0, and analyze its corresponding attributes. @@ -94,6 +94,38 @@ This rule identifies the usage of the `usermod` command to set a user's UID to 0 - Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). +---------------------------------- + +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-linux-credential-dumping-via-proc-filesystem.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-linux-credential-dumping-via-proc-filesystem.asciidoc index 7fd3385407..f519bf5623 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-linux-credential-dumping-via-proc-filesystem.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-linux-credential-dumping-via-proc-filesystem.asciidoc @@ -42,6 +42,38 @@ Identifies the execution of the mimipenguin exploit script which is linux adapta *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-linux-credential-dumping-via-unshadow.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-linux-credential-dumping-via-unshadow.asciidoc index 3c027fe719..70cea8c56e 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-linux-credential-dumping-via-unshadow.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-linux-credential-dumping-via-unshadow.asciidoc @@ -42,6 +42,38 @@ Identifies the execution of the unshadow utility which is part of John the Rippe *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-linux-hack-tool-launched.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-linux-hack-tool-launched.asciidoc index 6ba1a74b36..231c7bf678 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-linux-hack-tool-launched.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-linux-hack-tool-launched.asciidoc @@ -40,6 +40,39 @@ Monitors for the execution of different processes that might be used by attacker *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- We suggest to select "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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-linux-local-account-brute-force-detected.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-linux-local-account-brute-force-detected.asciidoc index 69324f7646..e2f003d909 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-linux-local-account-brute-force-detected.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-linux-local-account-brute-force-detected.asciidoc @@ -38,6 +38,38 @@ Identifies multiple consecutive login attempts executed by one process targeting *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-linux-ransomware-note-creation-detected.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-linux-ransomware-note-creation-detected.asciidoc index 4ca536e754..3d5b6eec45 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-linux-ransomware-note-creation-detected.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-linux-ransomware-note-creation-detected.asciidoc @@ -38,6 +38,38 @@ This rule identifies a sequence of a mass file encryption event in conjunction w *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-linux-ssh-x11-forwarding.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-linux-ssh-x11-forwarding.asciidoc index 7fb714fb88..9cf4dade17 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-linux-ssh-x11-forwarding.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-linux-ssh-x11-forwarding.asciidoc @@ -55,8 +55,8 @@ Attackers can leverage SSH X11 forwarding to capture a user's graphical desktop This rule looks for the execution of SSH in conjunction with command line arguments that are capable of setting up X11 forwarding. > **Note**: -> This investigation guide uses the {security-guide}/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. -> This investigation guide uses {security-guide}/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. #### Possible investigation steps diff --git a/docs/detections/prebuilt-rules/rule-details/potential-linux-tunneling-and-or-port-forwarding.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-linux-tunneling-and-or-port-forwarding.asciidoc index e892a83217..31ec47a972 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-linux-tunneling-and-or-port-forwarding.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-linux-tunneling-and-or-port-forwarding.asciidoc @@ -55,8 +55,8 @@ Attackers can leverage many utilities to clandestinely tunnel network communicat This rule looks for several utilities that are capable of setting up tunnel network communications by analyzing process names or command line arguments. > **Note**: -> This investigation guide uses the {security-guide}/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. -> This investigation guide uses {security-guide}/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. #### Possible investigation steps @@ -111,6 +111,36 @@ This rule looks for several utilities that are capable of setting up tunnel netw ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +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. + +#### 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. +- 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. +- 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. + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-lsass-clone-creation-via-psscapturesnapshot.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-lsass-clone-creation-via-psscapturesnapshot.asciidoc index 4e932f7134..fc2c3f8d01 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-lsass-clone-creation-via-psscapturesnapshot.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-lsass-clone-creation-via-psscapturesnapshot.asciidoc @@ -43,6 +43,22 @@ Identifies the creation of an LSASS process clone via PssCaptureSnapShot where t *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +This is meant to run only on datasources using Windows security event 4688 that captures the process clone creation. + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-lsass-memory-dump-via-psscapturesnapshot.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-lsass-memory-dump-via-psscapturesnapshot.asciidoc index ab6fa5b12a..c0c36b36e8 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-lsass-memory-dump-via-psscapturesnapshot.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-lsass-memory-dump-via-psscapturesnapshot.asciidoc @@ -42,6 +42,17 @@ Identifies suspicious access to an LSASS handle via PssCaptureSnapShot where two *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +This is meant to run only on datasources using Elastic Agent 7.14+ since versions prior to that will be missing the threshold +rule cardinality feature. + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-macos-ssh-brute-force-detected.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-macos-ssh-brute-force-detected.asciidoc index b31f90c3c8..07605f8c0c 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-macos-ssh-brute-force-detected.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-macos-ssh-brute-force-detected.asciidoc @@ -40,6 +40,38 @@ Identifies a high number (20) of macOS SSH KeyGen process executions from the sa *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### The following steps should be executed in order to add the Elastic Defend integration on a macOS 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, for MacOS it is recommended to select "Traditional Endpoints". +- 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-meterpreter-reverse-shell.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-meterpreter-reverse-shell.asciidoc index a333f2fb70..784242b913 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-meterpreter-reverse-shell.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-meterpreter-reverse-shell.asciidoc @@ -38,6 +38,51 @@ This detection rule identifies a sample of suspicious Linux system file reads us *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +This rule requires data coming in from one of the following integrations: +- Auditbeat +- Auditd Manager + +### Auditbeat Setup +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + +#### The following steps should be executed in order to add the Auditbeat on a Linux System: +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html. + +### 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" on a Linux 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. + +#### 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 the following additional audit rules are required to be added to the integration: + -w /proc/net/ -p r -k audit_proc + -w /etc/machine-id -p wa -k machineid + -w /etc/passwd -p wa -k passwd + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-microsoft-office-sandbox-evasion.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-microsoft-office-sandbox-evasion.asciidoc index 5068efa8ab..86e3409d3d 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-microsoft-office-sandbox-evasion.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-microsoft-office-sandbox-evasion.asciidoc @@ -42,6 +42,38 @@ Identifies the creation of a suspicious zip file prepended with special characte *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### The following steps should be executed in order to add the Elastic Defend integration on a macOS 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, for MacOS it is recommended to select "Traditional Endpoints". +- 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-modification-of-accessibility-binaries.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-modification-of-accessibility-binaries.asciidoc index 3549cf5af8..b467b9e7de 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-modification-of-accessibility-binaries.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-modification-of-accessibility-binaries.asciidoc @@ -56,12 +56,12 @@ Windows contains accessibility features that may be launched with a key combinat Adversaries may establish persistence and/or elevate privileges by executing malicious content triggered by accessibility features. Windows contains accessibility features that may be launched with a key combination before a user has logged in (ex: when the user is on the Windows logon screen). An adversary can modify the way these programs are launched to get a command prompt or backdoor without logging in to the system. -More details can be found [here](https://attack.mitre.org/techniques/T1546/008/). +More details can be found https://attack.mitre.org/techniques/T1546/008/. This rule looks for the execution of supposed accessibility binaries that don't match any of the accessibility features binaries' original file names, which is likely a custom binary deployed by the attacker. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps @@ -106,6 +106,20 @@ This rule looks for the execution of supposed accessibility binaries that don't +---------------------------------- + +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-network-scan-executed-from-host.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-network-scan-executed-from-host.asciidoc index 4df747b5cc..a0fcc727a4 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-network-scan-executed-from-host.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-network-scan-executed-from-host.asciidoc @@ -38,6 +38,39 @@ This threshold rule monitors for the rapid execution of unix utilities that are *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- We suggest to select "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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-non-standard-port-http-https-connection.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-non-standard-port-http-https-connection.asciidoc index f0a42b1a73..395e500b23 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-non-standard-port-http-https-connection.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-non-standard-port-http-https-connection.asciidoc @@ -54,8 +54,8 @@ Attackers may alter standard protocol ports, like using HTTP on port 8443 instea This rule looks for HTTP/HTTPS processes where the destination port is not any of the default 80/443 HTTP/HTTPS ports. > **Note**: -> This investigation guide uses the {security-guide}/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. -> This investigation guide uses {security-guide}/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. #### Possible investigation steps diff --git a/docs/detections/prebuilt-rules/rule-details/potential-okta-mfa-bombing-via-push-notifications.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-okta-mfa-bombing-via-push-notifications.asciidoc index 173ad39e49..23f23d16bb 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-okta-mfa-bombing-via-push-notifications.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-okta-mfa-bombing-via-push-notifications.asciidoc @@ -83,6 +83,15 @@ This rule detects when a user denies MFA Okta Verify push notifications twice, f ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-openssh-backdoor-logging-activity.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-openssh-backdoor-logging-activity.asciidoc index 1816e9d8d5..d061ff524e 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-openssh-backdoor-logging-activity.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-openssh-backdoor-logging-activity.asciidoc @@ -45,6 +45,53 @@ Identifies a Secure Shell (SSH) client or server process creating or writing to *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Auditbeat + +### 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. + +#### 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. +- 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. +- 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. + +### Auditbeat Setup +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + +#### The following steps should be executed in order to add the Auditbeat on a Linux System: +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html. + +#### Custom Ingest Pipeline +For versions <8.2, you need to add a custom ingest pipeline to populate `event.ingested` with @timestamp for non-elastic-agent indexes, like auditbeats/filebeat/winlogbeat etc. For more details to add a custom ingest pipeline refer to the https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-password-spraying-of-microsoft-365-user-accounts.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-password-spraying-of-microsoft-365-user-accounts.asciidoc index ff100cd27e..68366ea8d7 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-password-spraying-of-microsoft-365-user-accounts.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-password-spraying-of-microsoft-365-user-accounts.asciidoc @@ -46,6 +46,14 @@ Identifies a high number (25) of failed Microsoft 365 user authentication attemp ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-persistence-through-init-d-detected.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-persistence-through-init-d-detected.asciidoc index af74a933bf..ee9e06d00d 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-persistence-through-init-d-detected.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-persistence-through-init-d-detected.asciidoc @@ -61,8 +61,8 @@ Attackers can abuse files within the `/etc/init.d/` directory to run scripts, co This rule looks for the creation of new files within the `/etc/init.d/` directory. Executable files in these directories will automatically run at boot with root privileges. > **Note**: -> This investigation guide uses the {security-guide}/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. -> This investigation guide uses {security-guide}/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. #### Possible Investigation Steps - Investigate the file that was created or modified. @@ -113,6 +113,38 @@ This rule looks for the creation of new files within the `/etc/init.d/` director - Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). +---------------------------------- + +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-persistence-through-motd-file-creation-detected.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-persistence-through-motd-file-creation-detected.asciidoc index 284a961e3c..e74ba3db21 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-persistence-through-motd-file-creation-detected.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-persistence-through-motd-file-creation-detected.asciidoc @@ -59,8 +59,8 @@ Attackers can abuse message-of-the-day (motd) files to run scripts, commands or This rule identifies the creation of new files within the `/etc/update-motd.d/` or `/usr/lib/update-notifier/` directories. > **Note**: -> This investigation guide uses the {security-guide}/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. -> This investigation guide uses {security-guide}/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. #### Possible Investigation Steps @@ -107,6 +107,38 @@ This rule identifies the creation of new files within the `/etc/update-motd.d/` - Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). +---------------------------------- + +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-persistence-through-run-control-detected.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-persistence-through-run-control-detected.asciidoc index e105b5d456..ada9489de1 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-persistence-through-run-control-detected.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-persistence-through-run-control-detected.asciidoc @@ -61,8 +61,8 @@ There might still be users that use `rc.local` in a benign matter, so investigat Detection alerts from this rule indicate the creation of a new `/etc/rc.local` file. > **Note**: -> This investigation guide uses the {security-guide}/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. -> This investigation guide uses {security-guide}/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. #### Possible Investigation Steps @@ -110,6 +110,38 @@ Detection alerts from this rule indicate the creation of a new `/etc/rc.local` f - Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). +---------------------------------- + +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-persistence-through-systemd-udevd.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-persistence-through-systemd-udevd.asciidoc index 703daf57b9..dfda1c5a16 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-persistence-through-systemd-udevd.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-persistence-through-systemd-udevd.asciidoc @@ -41,6 +41,39 @@ Monitors for the creation of rule files that are used by systemd-udevd to manage *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- +## 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. + +#### 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. +- We suggest to select "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. +- 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. + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-persistence-via-atom-init-script-modification.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-persistence-via-atom-init-script-modification.asciidoc index 5871b85635..3e929943fe 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-persistence-via-atom-init-script-modification.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-persistence-via-atom-init-script-modification.asciidoc @@ -41,6 +41,38 @@ Identifies modifications to the Atom desktop text editor Init File. Adversaries *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### The following steps should be executed in order to add the Elastic Defend integration on a macOS 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, for MacOS it is recommended to select "Traditional Endpoints". +- 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-persistence-via-login-hook.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-persistence-via-login-hook.asciidoc index 163e0c1626..b1fc2e5aa5 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-persistence-via-login-hook.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-persistence-via-login-hook.asciidoc @@ -50,6 +50,38 @@ Identifies the creation or modification of the login window property list (plist Starting in Mac OS X 10.7 (Lion), users can specify certain applications to be re-opened when a user reboots their machine. This can be abused to establish or maintain persistence on a compromised system. ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### The following steps should be executed in order to add the Elastic Defend integration on a macOS 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, for MacOS it is recommended to select "Traditional Endpoints". +- 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-persistence-via-periodic-tasks.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-persistence-via-periodic-tasks.asciidoc index 7bdcbfdb32..9afbf60914 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-persistence-via-periodic-tasks.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-persistence-via-periodic-tasks.asciidoc @@ -42,6 +42,38 @@ Identifies the creation or modification of the default configuration for periodi *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### The following steps should be executed in order to add the Elastic Defend integration on a macOS 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, for MacOS it is recommended to select "Traditional Endpoints". +- 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-persistence-via-time-provider-modification.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-persistence-via-time-provider-modification.asciidoc index 747a15982b..ac755461a5 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-persistence-via-time-provider-modification.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-persistence-via-time-provider-modification.asciidoc @@ -57,7 +57,7 @@ The Time Provider architecture in Windows is responsible for obtaining accurate This rule identifies changes in the registry paths associated with Time Providers, specifically targeting the addition of new DLL files. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. ### Possible investigation steps diff --git a/docs/detections/prebuilt-rules/rule-details/potential-powershell-hacktool-script-by-function-names.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-powershell-hacktool-script-by-function-names.asciidoc index 7044a0de23..9ffa11573f 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-powershell-hacktool-script-by-function-names.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-powershell-hacktool-script-by-function-names.asciidoc @@ -56,7 +56,7 @@ PowerShell is one of the main tools system administrators use for automation, re Adversaries often exploit PowerShell's capabilities to execute malicious scripts and perform various attacks. This rule identifies known offensive tooling function names in PowerShell scripts, as attackers commonly use out-of-the-box tools without modifying the code. By monitoring these specific function names, the rule aims to detect and alert potential malicious PowerShell activity. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. ### Possible investigation steps @@ -114,6 +114,30 @@ Adversaries often exploit PowerShell's capabilities to execute malicious scripts ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- + +The 'PowerShell Script Block Logging' logging policy must be enabled. +Steps to implement the logging policy with with Advanced Audit Configuration: + +``` +Computer Configuration > +Administrative Templates > +Windows PowerShell > +Turn on PowerShell Script Block Logging (Enable) +``` + +Steps to implement the logging policy via registry: + +``` +reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1 +``` + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-privacy-control-bypass-via-localhost-secure-copy.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-privacy-control-bypass-via-localhost-secure-copy.asciidoc index 51d459877f..e5e5c6d69f 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-privacy-control-bypass-via-localhost-secure-copy.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-privacy-control-bypass-via-localhost-secure-copy.asciidoc @@ -41,6 +41,38 @@ Identifies use of the Secure Copy Protocol (SCP) to copy files locally by abusin *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### The following steps should be executed in order to add the Elastic Defend integration on a macOS 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, for MacOS it is recommended to select "Traditional Endpoints". +- 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-privacy-control-bypass-via-tccdb-modification.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-privacy-control-bypass-via-tccdb-modification.asciidoc index b61b029626..27e2b53792 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-privacy-control-bypass-via-tccdb-modification.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-privacy-control-bypass-via-tccdb-modification.asciidoc @@ -42,6 +42,38 @@ Identifies the use of sqlite3 to directly modify the Transparency, Consent, and *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### The following steps should be executed in order to add the Elastic Defend integration on a macOS 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, for MacOS it is recommended to select "Traditional Endpoints". +- 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-through-writable-docker-socket.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-through-writable-docker-socket.asciidoc index fa53b875dd..4e6d85babc 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-through-writable-docker-socket.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-through-writable-docker-socket.asciidoc @@ -41,6 +41,38 @@ This rule monitors for the usage of Docker runtime sockets to escalate privilege *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-container-misconfiguration.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-container-misconfiguration.asciidoc index f4a3967fda..46e2be0ed3 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-container-misconfiguration.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-container-misconfiguration.asciidoc @@ -42,6 +42,47 @@ This rule monitors for the execution of processes that interact with Linux conta *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + +Session View uses process data collected by the Elastic Defend integration, but this data is not always collected by default. Session View is available on enterprise subscription for versions 8.3 and above. +#### To confirm that Session View data is enabled: +- Go to “Manage → Policies”, and edit one or more of your Elastic Defend integration policies. +- Select the” Policy settings” tab, then scroll down to the “Linux event collection” section near the bottom. +- Check the box for “Process events”, and turn on the “Include session data” toggle. +- If you want to include file and network alerts in Session View, check the boxes for “Network and File events”. +- If you want to enable terminal output capture, turn on the “Capture terminal output” toggle. +For more information about the additional fields collected when this setting is enabled and the usage of Session View for Analysis refer to the https://www.elastic.co/guide/en/security/current/session-view.html. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-cve-2023-4911.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-cve-2023-4911.asciidoc index 4ab33d4073..2350694ce9 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-cve-2023-4911.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-cve-2023-4911.asciidoc @@ -41,6 +41,51 @@ This rule detects potential privilege escalation attempts through Looney Tunable *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + +Elastic Defend integration does not collect environment variable logging by default. +In order to capture this behavior, this rule requires a specific configuration option set within the advanced settings of the Elastic Defend integration. + #### To set up environment variable capture for an Elastic Agent policy: +- Go to “Security → Manage → Policies”. +- Select an “Elastic Agent policy”. +- Click “Show advanced settings”. +- Scroll down or search for “linux.advanced.capture_env_vars”. +- Enter the names of environment variables you want to capture, separated by commas. +- For this rule the linux.advanced.capture_env_vars variable should be set to "GLIBC_TUNABLES". +- Click “Save”. +After saving the integration change, the Elastic Agents running this policy will be updated and the rule will function properly. +For more information on capturing environment variables refer to the https://www.elastic.co/guide/en/security/current/environment-variable-capture.html. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-enlightenment.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-enlightenment.asciidoc index 4a6c0b2aa0..086f587653 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-enlightenment.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-enlightenment.asciidoc @@ -42,6 +42,38 @@ Identifies an attempt to exploit a local privilege escalation CVE-2022-37706 via *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-installerfiletakeover.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-installerfiletakeover.asciidoc index 8c8e5170c6..3ce9fe6e1e 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-installerfiletakeover.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-installerfiletakeover.asciidoc @@ -56,7 +56,7 @@ InstallerFileTakeOver is a weaponized escalation of privilege proof of concept ( This rule detects the default execution of the PoC, which overwrites the `elevation_service.exe` DACL and copies itself to the location to escalate privileges. An attacker is able to still take over any file that is not in use (locked), which is outside the scope of this rule. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps @@ -103,6 +103,20 @@ This rule detects the default execution of the PoC, which overwrites the `elevat - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-linux-dac-permissions.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-linux-dac-permissions.asciidoc index 69f4d7a0c6..cd1c2b0b77 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-linux-dac-permissions.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-linux-dac-permissions.asciidoc @@ -38,6 +38,38 @@ Identifies potential privilege escalation exploitation of DAC (Discretionary acc *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-overlayfs.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-overlayfs.asciidoc index 98d510db21..00b630a233 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-overlayfs.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-overlayfs.asciidoc @@ -42,6 +42,38 @@ Identifies an attempt to exploit a local privilege escalation (CVE-2023-2640 and *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-pkexec.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-pkexec.asciidoc index 9badfeb5cc..2bdb525eb7 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-pkexec.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-pkexec.asciidoc @@ -44,6 +44,38 @@ Identifies an attempt to exploit a local privilege escalation in polkit pkexec ( *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-python-cap-setuid.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-python-cap-setuid.asciidoc index 5229bba0a1..9c0c02adee 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-python-cap-setuid.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-python-cap-setuid.asciidoc @@ -38,6 +38,39 @@ This detection rule monitors for the execution of a system command with setuid o *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- We suggest to select "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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-recently-compiled-executable.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-recently-compiled-executable.asciidoc index 63e4124b3b..07bf5be968 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-recently-compiled-executable.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-recently-compiled-executable.asciidoc @@ -39,6 +39,38 @@ This rule monitors a sequence involving a program compilation event followed by *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-uid-int-max-bug-detected.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-uid-int-max-bug-detected.asciidoc index 6495da0a38..2e07bf9632 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-uid-int-max-bug-detected.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-privilege-escalation-via-uid-int-max-bug-detected.asciidoc @@ -42,6 +42,38 @@ This rule monitors for the execution of the systemd-run command by a user with a *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-privileged-escalation-via-samaccountname-spoofing.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-privileged-escalation-via-samaccountname-spoofing.asciidoc index 4db7888428..29a471ef6d 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-privileged-escalation-via-samaccountname-spoofing.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-privileged-escalation-via-samaccountname-spoofing.asciidoc @@ -49,6 +49,19 @@ Identifies a suspicious computer account name rename event, which may indicate a *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-process-injection-via-powershell.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-process-injection-via-powershell.asciidoc index ccc61b4e4d..8581573597 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-process-injection-via-powershell.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-process-injection-via-powershell.asciidoc @@ -90,6 +90,30 @@ Red Team tooling and malware developers take advantage of these capabilities to - 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 + + +[source, markdown] +---------------------------------- + +The 'PowerShell Script Block Logging' logging policy must be enabled. +Steps to implement the logging policy with with Advanced Audit Configuration: + +``` +Computer Configuration > +Administrative Templates > +Windows PowerShell > +Turn on PowerShell Script Block Logging (Enable) +``` + +Steps to implement the logging policy via registry: + +``` +reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1 +``` + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-protocol-tunneling-via-chisel-client.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-protocol-tunneling-via-chisel-client.asciidoc index 6bfc76c665..bf62d6b605 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-protocol-tunneling-via-chisel-client.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-protocol-tunneling-via-chisel-client.asciidoc @@ -55,8 +55,8 @@ Attackers can leverage `chisel` to clandestinely tunnel network communications a This rule looks for a sequence of command line arguments that are consistent with `chisel` client tunneling behavior, followed by a network event by an uncommon process. > **Note**: -> This investigation guide uses the {security-guide}/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. -> This investigation guide uses {security-guide}/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. #### Possible investigation steps @@ -109,6 +109,36 @@ This rule looks for a sequence of command line arguments that are consistent wit ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +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. + +#### 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. +- 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. +- 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. + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-protocol-tunneling-via-chisel-server.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-protocol-tunneling-via-chisel-server.asciidoc index ec0567189f..ab862db8d7 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-protocol-tunneling-via-chisel-server.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-protocol-tunneling-via-chisel-server.asciidoc @@ -55,8 +55,8 @@ Attackers can leverage `chisel` to clandestinely tunnel network communications a This rule looks for a sequence of command line arguments that are consistent with `chisel` server tunneling behavior, followed by a network event by an uncommon process. > **Note**: -> This investigation guide uses the {security-guide}/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. -> This investigation guide uses {security-guide}/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. #### Possible investigation steps @@ -109,6 +109,36 @@ This rule looks for a sequence of command line arguments that are consistent wit ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +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. + +#### 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. +- 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. +- 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. + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-protocol-tunneling-via-earthworm.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-protocol-tunneling-via-earthworm.asciidoc index 594522aade..7a19e430de 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-protocol-tunneling-via-earthworm.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-protocol-tunneling-via-earthworm.asciidoc @@ -58,8 +58,8 @@ Attackers can leverage `earthworm` to clandestinely tunnel network communication This rule looks for several command line arguments that are consistent with `earthworm` tunneling behavior. > **Note**: -> This investigation guide uses the {security-guide}/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. -> This investigation guide uses {security-guide}/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. #### Possible investigation steps @@ -110,6 +110,50 @@ This rule looks for several command line arguments that are consistent with `ear - Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. - Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). +---------------------------------- + +==== Setup + + +[source, markdown] +---------------------------------- +This rule requires data coming in either from Elastic Defend, or Auditbeat integration. + +### 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. + +#### 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. +- 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. +- 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. + +### Auditbeat Setup +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + +#### The following steps should be executed in order to add the Auditbeat on a Linux System: +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html. + +#### Custom Ingest Pipeline +For versions <8.2, you need to add a custom ingest pipeline to populate `event.ingested` with @timestamp for non-elastic-agent indexes, like auditbeats/filebeat/winlogbeat etc. For more details to add a custom ingest pipeline refer to the https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html. + + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-pspy-process-monitoring-detected.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-pspy-process-monitoring-detected.asciidoc index 39f3d54c5c..caf1d811eb 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-pspy-process-monitoring-detected.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-pspy-process-monitoring-detected.asciidoc @@ -39,6 +39,37 @@ This rule leverages auditd to monitor for processes scanning different processes *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +This rule requires data coming in from Auditd Manager. + +### 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" on a Linux 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. + +#### 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 the following additional audit rules are required to be added to the integration: + -- "-w /proc/ -p r -k audit_proc" + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-remote-code-execution-via-web-server.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-remote-code-execution-via-web-server.asciidoc index 6c6caac0ce..96878d4f73 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-remote-code-execution-via-web-server.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-remote-code-execution-via-web-server.asciidoc @@ -60,8 +60,8 @@ Adversaries may backdoor web servers with web shells to establish persistent acc This rule detects a web server process spawning script and command line interface programs, potentially indicating attackers executing commands using the web shell. > **Note**: -> This investigation guide uses the {security-guide}/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. -> This investigation guide uses {security-guide}/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. #### Possible investigation steps @@ -105,6 +105,38 @@ This rule detects a web server process spawning script and command line interfac - Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). +---------------------------------- + +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-remote-credential-access-via-registry.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-remote-credential-access-via-registry.asciidoc index 6c9080ec43..e70fcaa738 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-remote-credential-access-via-registry.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-remote-credential-access-via-registry.asciidoc @@ -84,6 +84,22 @@ Attackers can use tools like secretsdump.py or CrackMapExec to dump the registry - 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 + + +[source, markdown] +---------------------------------- + +This rule uses Elastic Endpoint file creation and system integration events for correlation. Both data should be collected from the host for this detection to work. + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-remote-desktop-shadowing-activity.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-remote-desktop-shadowing-activity.asciidoc index 26cf90811e..ee22da9e06 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-remote-desktop-shadowing-activity.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-remote-desktop-shadowing-activity.asciidoc @@ -45,6 +45,20 @@ Identifies the modification of the Remote Desktop Protocol (RDP) Shadow registry *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-remote-desktop-tunneling-detected.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-remote-desktop-tunneling-detected.asciidoc index 96cd096855..00778108a5 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-remote-desktop-tunneling-detected.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-remote-desktop-tunneling-detected.asciidoc @@ -87,6 +87,20 @@ This rule looks for command lines involving the `3389` port, which RDP uses by d +---------------------------------- + +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-reverse-shell-activity-via-terminal.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-reverse-shell-activity-via-terminal.asciidoc index efa411d691..c6a8e04a2c 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-reverse-shell-activity-via-terminal.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-reverse-shell-activity-via-terminal.asciidoc @@ -83,6 +83,21 @@ This rule identifies commands that are potentially related to reverse shell acti - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-reverse-shell-via-background-process.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-reverse-shell-via-background-process.asciidoc index b2231ecb9e..428e8605a6 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-reverse-shell-via-background-process.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-reverse-shell-via-background-process.asciidoc @@ -38,6 +38,38 @@ Monitors for the execution of background processes with process arguments capabl *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-reverse-shell-via-child.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-reverse-shell-via-child.asciidoc index 08a19ce260..eef0e18594 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-reverse-shell-via-child.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-reverse-shell-via-child.asciidoc @@ -40,6 +40,39 @@ This detection rule identifies suspicious network traffic patterns associated wi *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- We suggest to select "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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-reverse-shell-via-java.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-reverse-shell-via-java.asciidoc index 02986dc7bd..40270f8fae 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-reverse-shell-via-java.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-reverse-shell-via-java.asciidoc @@ -40,6 +40,38 @@ This detection rule identifies the execution of a Linux shell process from a Jav *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-reverse-shell-via-suspicious-binary.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-reverse-shell-via-suspicious-binary.asciidoc index 56de923426..e67fd96680 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-reverse-shell-via-suspicious-binary.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-reverse-shell-via-suspicious-binary.asciidoc @@ -40,6 +40,38 @@ This detection rule detects the creation of a shell through a chain consisting o *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-reverse-shell-via-suspicious-child-process.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-reverse-shell-via-suspicious-child-process.asciidoc index 9e827cd99d..ba28533a51 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-reverse-shell-via-suspicious-child-process.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-reverse-shell-via-suspicious-child-process.asciidoc @@ -40,6 +40,38 @@ This detection rule detects the creation of a shell through a suspicious process *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-reverse-shell-via-udp.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-reverse-shell-via-udp.asciidoc index 9ff1ce54f2..924f916075 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-reverse-shell-via-udp.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-reverse-shell-via-udp.asciidoc @@ -40,6 +40,48 @@ This detection rule identifies suspicious network traffic patterns associated wi *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +This rule requires data coming in from one of the following integrations: +- Auditbeat +- Auditd Manager + +### Auditbeat Setup +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + +#### The following steps should be executed in order to add the Auditbeat on a Linux System: +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html. + +### 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" on a Linux 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. + +#### 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 to be added to the integration. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-reverse-shell.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-reverse-shell.asciidoc index 550e908d8c..f058df61ca 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-reverse-shell.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-reverse-shell.asciidoc @@ -40,6 +40,38 @@ This detection rule identifies suspicious network traffic patterns associated wi *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-shadow-credentials-added-to-ad-object.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-shadow-credentials-added-to-ad-object.asciidoc index 2cefe0e47b..4161a12ce7 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-shadow-credentials-added-to-ad-object.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-shadow-credentials-added-to-ad-object.asciidoc @@ -84,6 +84,35 @@ Attackers with write privileges on this attribute over an object can abuse it to - 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 + + +[source, markdown] +---------------------------------- + +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 User objects, so we need to set up an AuditRule using https://github.com/OTRF/Set-AuditRule. +As this specifies the msDS-KeyCredentialLink Attribute GUID, it is expected to be low noise. + +``` +Set-AuditRule -AdObjectPath 'AD:\CN=Users,DC=Domain,DC=com' -WellKnownSidType WorldSid -Rights WriteProperty -InheritanceFlags Children -AttributeGUID 5b47d60f-6090-40b2-9f37-2a4de88f3063 -AuditFlags Success +``` + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-shadow-file-read-via-command-line-utilities.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-shadow-file-read-via-command-line-utilities.asciidoc index f38aeeaf07..a2122b785a 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-shadow-file-read-via-command-line-utilities.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-shadow-file-read-via-command-line-utilities.asciidoc @@ -43,6 +43,38 @@ Identifies access to the /etc/shadow file via the commandline using standard sys *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-shell-via-wildcard-injection-detected.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-shell-via-wildcard-injection-detected.asciidoc index 09114394f9..15b05da820 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-shell-via-wildcard-injection-detected.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-shell-via-wildcard-injection-detected.asciidoc @@ -41,6 +41,38 @@ This rule monitors for the execution of a set of linux binaries, that are potent *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-ssh-it-ssh-worm-downloaded.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-ssh-it-ssh-worm-downloaded.asciidoc index 8563643698..62431ab0f4 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-ssh-it-ssh-worm-downloaded.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-ssh-it-ssh-worm-downloaded.asciidoc @@ -41,6 +41,39 @@ Identifies processes that are capable of downloading files with command line arg *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- We suggest to select "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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-successful-linux-ftp-brute-force-attack-detected.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-successful-linux-ftp-brute-force-attack-detected.asciidoc index de1e49ff21..09607e3688 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-successful-linux-ftp-brute-force-attack-detected.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-successful-linux-ftp-brute-force-attack-detected.asciidoc @@ -38,6 +38,48 @@ An FTP (file transfer protocol) brute force attack is a method where an attacker *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +This rule requires data coming in from one of the following integrations: +- Auditbeat +- Auditd Manager + +### Auditbeat Setup +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + +#### The following steps should be executed in order to add the Auditbeat on a Linux System: +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html. + +### 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" on a Linux 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. + +#### 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 to be added to the integration. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-successful-linux-rdp-brute-force-attack-detected.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-successful-linux-rdp-brute-force-attack-detected.asciidoc index e247daba5f..77560dba90 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-successful-linux-rdp-brute-force-attack-detected.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-successful-linux-rdp-brute-force-attack-detected.asciidoc @@ -38,6 +38,48 @@ An RDP (Remote Desktop Protocol) brute force attack involves an attacker repeate *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +This rule requires data coming in from one of the following integrations: +- Auditbeat +- Auditd Manager + +### Auditbeat Setup +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + +#### The following steps should be executed in order to add the Auditbeat on a Linux System: +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html. + +### 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" on a Linux 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. + +#### 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 to be added to the integration. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-successful-ssh-brute-force-attack.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-successful-ssh-brute-force-attack.asciidoc index e13749398d..b6dbf764e0 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-successful-ssh-brute-force-attack.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-successful-ssh-brute-force-attack.asciidoc @@ -73,6 +73,45 @@ The rule identifies consecutive SSH login failures followed by a successful logi - 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 + + +[source, markdown] +---------------------------------- + +This rule requires data coming in from one of the following integrations: +- Auditbeat +- Filebeat + +### Auditbeat Setup +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + +#### The following steps should be executed in order to add the Auditbeat on a Linux System: +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html. + +### Filebeat Setup +Filebeat is a lightweight shipper for forwarding and centralizing log data. Installed as an agent on your servers, Filebeat monitors the log files or locations that you specify, collects log events, and forwards them either to Elasticsearch or Logstash for indexing. + +#### The following steps should be executed in order to add the Filebeat on a Linux System: +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/filebeat/current/setup-repositories.html. +- To run Filebeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/running-on-docker.html. +- To run Filebeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/running-on-kubernetes.html. +- For quick start information for Filebeat refer to the https://www.elastic.co/guide/en/beats/filebeat/8.11/filebeat-installation-configuration.html. +- For complete “Setup and Run Filebeat” information refer to the https://www.elastic.co/guide/en/beats/filebeat/current/setting-up-and-running.html. + +#### Rule Specific Setup Note +- This rule requires the “Filebeat System Module” to be enabled. +- The system module collects and parses logs created by the system logging service of common Unix/Linux based distributions. +- To run the system module of Filebeat on Linux follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-system.html. + + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-sudo-hijacking-detected.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-sudo-hijacking-detected.asciidoc index 6b9010b5e4..9c8f441f80 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-sudo-hijacking-detected.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-sudo-hijacking-detected.asciidoc @@ -43,6 +43,38 @@ Identifies the creation of a sudo binary located at /usr/bin/sudo. Attackers may *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-sudo-privilege-escalation-via-cve-2019-14287.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-sudo-privilege-escalation-via-cve-2019-14287.asciidoc index da67a3987e..f3291f5365 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-sudo-privilege-escalation-via-cve-2019-14287.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-sudo-privilege-escalation-via-cve-2019-14287.asciidoc @@ -41,6 +41,38 @@ This rule monitors for the execution of a suspicious sudo command that is levera *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-sudo-token-manipulation-via-process-injection.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-sudo-token-manipulation-via-process-injection.asciidoc index 7e7b9b8971..7b9d7ebb83 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-sudo-token-manipulation-via-process-injection.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-sudo-token-manipulation-via-process-injection.asciidoc @@ -40,6 +40,38 @@ This rule detects potential sudo token manipulation attacks through process inje *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-suspicious-debugfs-root-device-access.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-suspicious-debugfs-root-device-access.asciidoc index 43266cbd0b..4b274d2fda 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-suspicious-debugfs-root-device-access.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-suspicious-debugfs-root-device-access.asciidoc @@ -42,6 +42,38 @@ This rule monitors for the usage of the built-in Linux DebugFS utility to access *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-unauthorized-access-via-wildcard-injection-detected.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-unauthorized-access-via-wildcard-injection-detected.asciidoc index eeed8bee7c..cdd8f95cd0 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-unauthorized-access-via-wildcard-injection-detected.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-unauthorized-access-via-wildcard-injection-detected.asciidoc @@ -43,6 +43,38 @@ This rule monitors for the execution of the "chown" and "chmod" commands with co *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-upgrade-of-non-interactive-shell.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-upgrade-of-non-interactive-shell.asciidoc index fc21b1c71b..a976080e11 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-upgrade-of-non-interactive-shell.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-upgrade-of-non-interactive-shell.asciidoc @@ -40,6 +40,38 @@ Identifies when a non-interactive terminal (tty) is being upgraded to a fully in *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/potential-windows-error-manager-masquerading.asciidoc b/docs/detections/prebuilt-rules/rule-details/potential-windows-error-manager-masquerading.asciidoc index bd93808e36..1030f25683 100644 --- a/docs/detections/prebuilt-rules/rule-details/potential-windows-error-manager-masquerading.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potential-windows-error-manager-masquerading.asciidoc @@ -59,7 +59,7 @@ By examining the specific traits of Windows binaries -- such as process trees, c This rule identifies a potential malicious process masquerading as `wermgr.exe` or `WerFault.exe`, by looking for a process creation with no arguments followed by a network connection. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps diff --git a/docs/detections/prebuilt-rules/rule-details/potentially-successful-mfa-bombing-via-push-notifications.asciidoc b/docs/detections/prebuilt-rules/rule-details/potentially-successful-mfa-bombing-via-push-notifications.asciidoc index b7562f0d97..638d74d695 100644 --- a/docs/detections/prebuilt-rules/rule-details/potentially-successful-mfa-bombing-via-push-notifications.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/potentially-successful-mfa-bombing-via-push-notifications.asciidoc @@ -82,6 +82,14 @@ This rule detects when a user denies MFA Okta Verify push notifications twice, f - Review and update your incident response plans and security policies based on the findings from the incident. ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/powershell-kerberos-ticket-dump.asciidoc b/docs/detections/prebuilt-rules/rule-details/powershell-kerberos-ticket-dump.asciidoc index 0d95941272..db59bc9693 100644 --- a/docs/detections/prebuilt-rules/rule-details/powershell-kerberos-ticket-dump.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/powershell-kerberos-ticket-dump.asciidoc @@ -93,6 +93,30 @@ This rule indicates the use of scripts that contain code capable of dumping Kerb ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- + +The 'PowerShell Script Block Logging' logging policy must be enabled. +Steps to implement the logging policy with Advanced Audit Configuration: + +``` +Computer Configuration > +Administrative Templates > +Windows PowerShell > +Turn on PowerShell Script Block Logging (Enable) +``` + +Steps to implement the logging policy via registry: + +``` +reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1 +``` + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/powershell-kerberos-ticket-request.asciidoc b/docs/detections/prebuilt-rules/rule-details/powershell-kerberos-ticket-request.asciidoc index 7eec5df28e..399ce471cd 100644 --- a/docs/detections/prebuilt-rules/rule-details/powershell-kerberos-ticket-request.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/powershell-kerberos-ticket-request.asciidoc @@ -68,7 +68,7 @@ Attackers can use PowerShell to request these Kerberos tickets, with the intent - Contact the account owner and confirm whether they are aware of this activity. - Check if the script has any other functionality that can be potentially malicious. - Investigate other alerts associated with the user/host during the past 48 hours. -- Review event ID [4769](https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4769) related to this account and service name for additional information. +- Review event ID https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4769 related to this account and service name for additional information. ### False positive analysis @@ -83,6 +83,30 @@ Attackers can use PowerShell to request these Kerberos tickets, with the intent - 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 + + +[source, markdown] +---------------------------------- + +The 'PowerShell Script Block Logging' logging policy must be enabled. +Steps to implement the logging policy with with Advanced Audit Configuration: + +``` +Computer Configuration > +Administrative Templates > +Windows PowerShell > +Turn on PowerShell Script Block Logging (Enable) +``` + +Steps to implement the logging policy via registry: + +``` +reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1 +``` + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/powershell-keylogging-script.asciidoc b/docs/detections/prebuilt-rules/rule-details/powershell-keylogging-script.asciidoc index 029ecd4426..dd88409925 100644 --- a/docs/detections/prebuilt-rules/rule-details/powershell-keylogging-script.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/powershell-keylogging-script.asciidoc @@ -87,6 +87,30 @@ Attackers can abuse PowerShell capabilities to capture user keystrokes with the - 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 + + +[source, markdown] +---------------------------------- + +The 'PowerShell Script Block Logging' logging policy must be enabled. +Steps to implement the logging policy with with Advanced Audit Configuration: + +``` +Computer Configuration > +Administrative Templates > +Windows PowerShell > +Turn on PowerShell Script Block Logging (Enable) +``` + +Steps to implement the logging policy via registry: + +``` +reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1 +``` + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/powershell-mailbox-collection-script.asciidoc b/docs/detections/prebuilt-rules/rule-details/powershell-mailbox-collection-script.asciidoc index 2c08a2f1ef..e045773cfe 100644 --- a/docs/detections/prebuilt-rules/rule-details/powershell-mailbox-collection-script.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/powershell-mailbox-collection-script.asciidoc @@ -88,6 +88,30 @@ This rule identifies scripts that contains methods and classes that can be abuse - 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 + + +[source, markdown] +---------------------------------- + +The 'PowerShell Script Block Logging' logging policy must be enabled. +Steps to implement the logging policy with with Advanced Audit Configuration: + +``` +Computer Configuration > +Administrative Templates > +Windows PowerShell > +Turn on PowerShell Script Block Logging (Enable) +``` + +Steps to implement the logging policy via registry: + +``` +reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1 +``` + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/powershell-minidump-script.asciidoc b/docs/detections/prebuilt-rules/rule-details/powershell-minidump-script.asciidoc index e29161ecdc..eab7427af5 100644 --- a/docs/detections/prebuilt-rules/rule-details/powershell-minidump-script.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/powershell-minidump-script.asciidoc @@ -86,6 +86,30 @@ Attackers can abuse Process Memory Dump capabilities to extract credentials from - 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 + + +[source, markdown] +---------------------------------- + +The 'PowerShell Script Block Logging' logging policy must be enabled. +Steps to implement the logging policy with with Advanced Audit Configuration: + +``` +Computer Configuration > +Administrative Templates > +Windows PowerShell > +Turn on PowerShell Script Block Logging (Enable) +``` + +Steps to implement the logging policy via registry: + +``` +reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1 +``` + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/powershell-psreflect-script.asciidoc b/docs/detections/prebuilt-rules/rule-details/powershell-psreflect-script.asciidoc index be972d7609..dc18eff92d 100644 --- a/docs/detections/prebuilt-rules/rule-details/powershell-psreflect-script.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/powershell-psreflect-script.asciidoc @@ -61,7 +61,7 @@ Although this is an interesting project for every developer and admin out there, Detecting the core implementation of PSReflect means detecting most of the tooling that uses Windows API through PowerShell, enabling defenders to discover tools being dropped in the environment. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps @@ -115,6 +115,31 @@ Detecting the core implementation of PSReflect means detecting most of the tooli - 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 + + +[source, markdown] +---------------------------------- + +The 'PowerShell Script Block Logging' logging policy must be configured (Enable). + +Steps to implement the logging policy with with Advanced Audit Configuration: + +``` +Computer Configuration > +Administrative Templates > +Windows PowerShell > +Turn on PowerShell Script Block Logging (Enable) +``` + +Steps to implement the logging policy via registry: + +``` +reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1 +``` + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/powershell-script-with-archive-compression-capabilities.asciidoc b/docs/detections/prebuilt-rules/rule-details/powershell-script-with-archive-compression-capabilities.asciidoc index 1c5b406939..a91b71a3b9 100644 --- a/docs/detections/prebuilt-rules/rule-details/powershell-script-with-archive-compression-capabilities.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/powershell-script-with-archive-compression-capabilities.asciidoc @@ -40,6 +40,29 @@ Identifies the use of Cmdlets and methods related to archive compression activit *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- +The 'PowerShell Script Block Logging' logging policy must be enabled. +Steps to implement the logging policy with Advanced Audit Configuration: + +``` +Computer Configuration > +Administrative Templates > +Windows PowerShell > +Turn on PowerShell Script Block Logging (Enable) +``` + +Steps to implement the logging policy via registry: + +``` +reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1 +``` + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/powershell-script-with-discovery-capabilities.asciidoc b/docs/detections/prebuilt-rules/rule-details/powershell-script-with-discovery-capabilities.asciidoc index 9dc0a01e10..402d7874d2 100644 --- a/docs/detections/prebuilt-rules/rule-details/powershell-script-with-discovery-capabilities.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/powershell-script-with-discovery-capabilities.asciidoc @@ -41,6 +41,29 @@ Identifies the use of Cmdlets and methods related to discovery activities. Attac *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- +The 'PowerShell Script Block Logging' logging policy must be enabled. +Steps to implement the logging policy with Advanced Audit Configuration: + +``` +Computer Configuration > +Administrative Templates > +Windows PowerShell > +Turn on PowerShell Script Block Logging (Enable) +``` + +Steps to implement the logging policy via registry: + +``` +reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1 +``` + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/powershell-script-with-log-clear-capabilities.asciidoc b/docs/detections/prebuilt-rules/rule-details/powershell-script-with-log-clear-capabilities.asciidoc index 713a108ee2..8f41fa987b 100644 --- a/docs/detections/prebuilt-rules/rule-details/powershell-script-with-log-clear-capabilities.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/powershell-script-with-log-clear-capabilities.asciidoc @@ -43,6 +43,29 @@ Identifies the use of Cmdlets and methods related to Windows event log deletion *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- +The 'PowerShell Script Block Logging' logging policy must be enabled. +Steps to implement the logging policy with Advanced Audit Configuration: + +``` +Computer Configuration > +Administrative Templates > +Windows PowerShell > +Turn on PowerShell Script Block Logging (Enable) +``` + +Steps to implement the logging policy via registry: + +``` +reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1 +``` + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/powershell-script-with-password-policy-discovery-capabilities.asciidoc b/docs/detections/prebuilt-rules/rule-details/powershell-script-with-password-policy-discovery-capabilities.asciidoc index 8dcad372a3..442a0fb08b 100644 --- a/docs/detections/prebuilt-rules/rule-details/powershell-script-with-password-policy-discovery-capabilities.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/powershell-script-with-password-policy-discovery-capabilities.asciidoc @@ -41,6 +41,29 @@ Identifies the use of Cmdlets and methods related to remote execution activities *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- +The 'PowerShell Script Block Logging' logging policy must be enabled. +Steps to implement the logging policy with Advanced Audit Configuration: + +``` +Computer Configuration > +Administrative Templates > +Windows PowerShell > +Turn on PowerShell Script Block Logging (Enable) +``` + +Steps to implement the logging policy via registry: + +``` +reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1 +``` + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/powershell-script-with-remote-execution-capabilities-via-winrm.asciidoc b/docs/detections/prebuilt-rules/rule-details/powershell-script-with-remote-execution-capabilities-via-winrm.asciidoc index 1b16e5df29..c6889358f0 100644 --- a/docs/detections/prebuilt-rules/rule-details/powershell-script-with-remote-execution-capabilities-via-winrm.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/powershell-script-with-remote-execution-capabilities-via-winrm.asciidoc @@ -45,6 +45,29 @@ Identifies the use of Cmdlets and methods related to remote execution activities *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- +The 'PowerShell Script Block Logging' logging policy must be enabled. +Steps to implement the logging policy with Advanced Audit Configuration: + +``` +Computer Configuration > +Administrative Templates > +Windows PowerShell > +Turn on PowerShell Script Block Logging (Enable) +``` + +Steps to implement the logging policy via registry: + +``` +reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1 +``` + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/powershell-script-with-token-impersonation-capabilities.asciidoc b/docs/detections/prebuilt-rules/rule-details/powershell-script-with-token-impersonation-capabilities.asciidoc index 6dccd75f92..a5f27bfcba 100644 --- a/docs/detections/prebuilt-rules/rule-details/powershell-script-with-token-impersonation-capabilities.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/powershell-script-with-token-impersonation-capabilities.asciidoc @@ -58,7 +58,7 @@ PowerShell is one of the main tools system administrators use for automation, re Adversaries can abuse PowerShell to perform token impersonation, which involves duplicating and impersonating another user's token to escalate privileges and bypass access controls. This rule identifies scripts containing PowerShell functions, structures, or Windows API functions related to token impersonation/theft. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. ### Possible investigation steps @@ -108,6 +108,29 @@ Adversaries can abuse PowerShell to perform token impersonation, which involves - 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 + + +[source, markdown] +---------------------------------- +The 'PowerShell Script Block Logging' logging policy must be configured (Enable). + +Steps to implement the logging policy with with Advanced Audit Configuration: + +``` +Computer Configuration > +Administrative Templates > +Windows PowerShell > +Turn on PowerShell Script Block Logging (Enable) +``` + +Steps to implement the logging policy via registry: + +``` +reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1 +``` +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/powershell-script-with-webcam-video-capture-capabilities.asciidoc b/docs/detections/prebuilt-rules/rule-details/powershell-script-with-webcam-video-capture-capabilities.asciidoc index db8c017eb6..b424fb0287 100644 --- a/docs/detections/prebuilt-rules/rule-details/powershell-script-with-webcam-video-capture-capabilities.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/powershell-script-with-webcam-video-capture-capabilities.asciidoc @@ -41,6 +41,29 @@ Detects PowerShell scripts that can be used to record webcam video. Attackers ca *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- +The 'PowerShell Script Block Logging' logging policy must be enabled. +Steps to implement the logging policy with Advanced Audit Configuration: + +``` +Computer Configuration > +Administrative Templates > +Windows PowerShell > +Turn on PowerShell Script Block Logging (Enable) +``` + +Steps to implement the logging policy via registry: + +``` +reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1 +``` + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/powershell-share-enumeration-script.asciidoc b/docs/detections/prebuilt-rules/rule-details/powershell-share-enumeration-script.asciidoc index 6031e15585..583b5e8936 100644 --- a/docs/detections/prebuilt-rules/rule-details/powershell-share-enumeration-script.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/powershell-share-enumeration-script.asciidoc @@ -84,6 +84,31 @@ Attackers can use PowerShell to enumerate shares to search for sensitive data li - 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 + + +[source, markdown] +---------------------------------- + +The 'PowerShell Script Block Logging' logging policy must be configured (Enable). + +Steps to implement the logging policy with with Advanced Audit Configuration: + +``` +Computer Configuration > +Administrative Templates > +Windows PowerShell > +Turn on PowerShell Script Block Logging (Enable) +``` + +Steps to implement the logging policy via registry: + +``` +reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1 +``` + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/powershell-suspicious-discovery-related-windows-api-functions.asciidoc b/docs/detections/prebuilt-rules/rule-details/powershell-suspicious-discovery-related-windows-api-functions.asciidoc index 2ac106bb7a..5f70ea7743 100644 --- a/docs/detections/prebuilt-rules/rule-details/powershell-suspicious-discovery-related-windows-api-functions.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/powershell-suspicious-discovery-related-windows-api-functions.asciidoc @@ -85,6 +85,30 @@ Attackers can use PowerShell to interact with the Win32 API to bypass command li - 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 + + +[source, markdown] +---------------------------------- + +The 'PowerShell Script Block Logging' logging policy must be enabled. +Steps to implement the logging policy with with Advanced Audit Configuration: + +``` +Computer Configuration > +Administrative Templates > +Windows PowerShell > +Turn on PowerShell Script Block Logging (Enable) +``` + +Steps to implement the logging policy via registry: + +``` +reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1 +``` + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/powershell-suspicious-payload-encoded-and-compressed.asciidoc b/docs/detections/prebuilt-rules/rule-details/powershell-suspicious-payload-encoded-and-compressed.asciidoc index ff64e6e8f4..3e8648deac 100644 --- a/docs/detections/prebuilt-rules/rule-details/powershell-suspicious-payload-encoded-and-compressed.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/powershell-suspicious-payload-encoded-and-compressed.asciidoc @@ -54,7 +54,7 @@ PowerShell is one of the main tools system administrators use for automation, re Attackers can embed compressed and encoded payloads in scripts to load directly into the memory without touching the disk. This strategy can circumvent string and file-based security protections. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps @@ -105,6 +105,30 @@ Attackers can embed compressed and encoded payloads in scripts to load directly - 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 + + +[source, markdown] +---------------------------------- + +The 'PowerShell Script Block Logging' logging policy must be enabled. +Steps to implement the logging policy with with Advanced Audit Configuration: + +``` +Computer Configuration > +Administrative Templates > +Windows PowerShell > +Turn on PowerShell Script Block Logging (Enable) +``` + +Steps to implement the logging policy via registry: + +``` +reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1 +``` + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/powershell-suspicious-script-with-audio-capture-capabilities.asciidoc b/docs/detections/prebuilt-rules/rule-details/powershell-suspicious-script-with-audio-capture-capabilities.asciidoc index 1961d36df4..c6bab2d44f 100644 --- a/docs/detections/prebuilt-rules/rule-details/powershell-suspicious-script-with-audio-capture-capabilities.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/powershell-suspicious-script-with-audio-capture-capabilities.asciidoc @@ -87,6 +87,30 @@ Attackers can use PowerShell to interact with the Windows API with the intent of - 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 + + +[source, markdown] +---------------------------------- + +The 'PowerShell Script Block Logging' logging policy must be enabled. +Steps to implement the logging policy with with Advanced Audit Configuration: + +``` +Computer Configuration > +Administrative Templates > +Windows PowerShell > +Turn on PowerShell Script Block Logging (Enable) +``` + +Steps to implement the logging policy via registry: + +``` +reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1 +``` + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/powershell-suspicious-script-with-clipboard-retrieval-capabilities.asciidoc b/docs/detections/prebuilt-rules/rule-details/powershell-suspicious-script-with-clipboard-retrieval-capabilities.asciidoc index 93f1e200e5..e978187305 100644 --- a/docs/detections/prebuilt-rules/rule-details/powershell-suspicious-script-with-clipboard-retrieval-capabilities.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/powershell-suspicious-script-with-clipboard-retrieval-capabilities.asciidoc @@ -87,6 +87,30 @@ Attackers can abuse PowerShell capabilities to get the contents of the clipboard - 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 + + +[source, markdown] +---------------------------------- + +The 'PowerShell Script Block Logging' logging policy must be enabled. +Steps to implement the logging policy with with Advanced Audit Configuration: + +``` +Computer Configuration > +Administrative Templates > +Windows PowerShell > +Turn on PowerShell Script Block Logging (Enable) +``` + +Steps to implement the logging policy via registry: + +``` +reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1 +``` + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/powershell-suspicious-script-with-screenshot-capabilities.asciidoc b/docs/detections/prebuilt-rules/rule-details/powershell-suspicious-script-with-screenshot-capabilities.asciidoc index 934c4ceaa2..563e142684 100644 --- a/docs/detections/prebuilt-rules/rule-details/powershell-suspicious-script-with-screenshot-capabilities.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/powershell-suspicious-script-with-screenshot-capabilities.asciidoc @@ -85,6 +85,30 @@ Attackers can abuse PowerShell capabilities and take screen captures of desktops - 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 + + +[source, markdown] +---------------------------------- + +The 'PowerShell Script Block Logging' logging policy must be enabled. +Steps to implement the logging policy with with Advanced Audit Configuration: + +``` +Computer Configuration > +Administrative Templates > +Windows PowerShell > +Turn on PowerShell Script Block Logging (Enable) +``` + +Steps to implement the logging policy via registry: + +``` +reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1 +``` + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/privilege-escalation-via-cap-chown-cap-fowner-capabilities.asciidoc b/docs/detections/prebuilt-rules/rule-details/privilege-escalation-via-cap-chown-cap-fowner-capabilities.asciidoc index d7074b03a4..97b132095e 100644 --- a/docs/detections/prebuilt-rules/rule-details/privilege-escalation-via-cap-chown-cap-fowner-capabilities.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/privilege-escalation-via-cap-chown-cap-fowner-capabilities.asciidoc @@ -40,6 +40,38 @@ Identifies instances where a processes (granted CAP_CHOWN and/or CAP_FOWNER capa *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +This rule requires data coming in from Auditd Manager. + +### 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" on a Linux 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. + +#### 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 the following additional audit rules are required to be added to the integration: + -- "-w /etc/ -p rwxa -k audit_recursive_etc" + -- "-w /root/ -p rwxa -k audit_root" + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/privilege-escalation-via-cap-setuid-setgid-capabilities.asciidoc b/docs/detections/prebuilt-rules/rule-details/privilege-escalation-via-cap-setuid-setgid-capabilities.asciidoc index d3b2742f49..38d7aa2ca2 100644 --- a/docs/detections/prebuilt-rules/rule-details/privilege-escalation-via-cap-setuid-setgid-capabilities.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/privilege-escalation-via-cap-setuid-setgid-capabilities.asciidoc @@ -38,6 +38,38 @@ Identifies instances where a process (granted CAP_SETUID and/or CAP_SETGID capab *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/privilege-escalation-via-gdb-cap-sys-ptrace.asciidoc b/docs/detections/prebuilt-rules/rule-details/privilege-escalation-via-gdb-cap-sys-ptrace.asciidoc index d4936fa642..2a54f51403 100644 --- a/docs/detections/prebuilt-rules/rule-details/privilege-escalation-via-gdb-cap-sys-ptrace.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/privilege-escalation-via-gdb-cap-sys-ptrace.asciidoc @@ -38,6 +38,38 @@ Identifies instances where GDB (granted the CAP_SYS_PTRACE capability) is execut *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/privilege-escalation-via-named-pipe-impersonation.asciidoc b/docs/detections/prebuilt-rules/rule-details/privilege-escalation-via-named-pipe-impersonation.asciidoc index db8ea324f7..4ee9b7e15e 100644 --- a/docs/detections/prebuilt-rules/rule-details/privilege-escalation-via-named-pipe-impersonation.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/privilege-escalation-via-named-pipe-impersonation.asciidoc @@ -62,7 +62,7 @@ A named pipe is a type of inter-process communication (IPC) mechanism used in op Attackers can abuse named pipes to elevate their privileges by impersonating the security context in which they execute code. Metasploit, for example, creates a service and a random pipe, and then uses the service to connect to the pipe and impersonate the service security context, which is SYSTEM. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps @@ -104,6 +104,20 @@ Attackers can abuse named pipes to elevate their privileges by impersonating the - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/privilege-escalation-via-rogue-named-pipe-impersonation.asciidoc b/docs/detections/prebuilt-rules/rule-details/privilege-escalation-via-rogue-named-pipe-impersonation.asciidoc index 40f5d8450f..1421c81d31 100644 --- a/docs/detections/prebuilt-rules/rule-details/privilege-escalation-via-rogue-named-pipe-impersonation.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/privilege-escalation-via-rogue-named-pipe-impersonation.asciidoc @@ -43,6 +43,23 @@ Identifies a privilege escalation attempt via rogue named pipe impersonation. An *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +Named Pipe Creation Events need to be enabled within the Sysmon configuration by including the following settings: +`condition equal "contains" and keyword equal "pipe"` + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/privilege-escalation-via-root-crontab-file-modification.asciidoc b/docs/detections/prebuilt-rules/rule-details/privilege-escalation-via-root-crontab-file-modification.asciidoc index 7c60c25b08..7a6310654b 100644 --- a/docs/detections/prebuilt-rules/rule-details/privilege-escalation-via-root-crontab-file-modification.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/privilege-escalation-via-root-crontab-file-modification.asciidoc @@ -41,6 +41,38 @@ Identifies modifications to the root crontab file. Adversaries may overwrite thi *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### The following steps should be executed in order to add the Elastic Defend integration on a macOS 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, for MacOS it is recommended to select "Traditional Endpoints". +- 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/privileged-account-brute-force.asciidoc b/docs/detections/prebuilt-rules/rule-details/privileged-account-brute-force.asciidoc index 8e7312530b..b975059687 100644 --- a/docs/detections/prebuilt-rules/rule-details/privileged-account-brute-force.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/privileged-account-brute-force.asciidoc @@ -51,12 +51,12 @@ Identifies multiple consecutive logon failures targeting an Admin account from t ### Investigating Privileged Account Brute Force -Adversaries with no prior knowledge of legitimate credentials within the system or environment may guess passwords to attempt access to accounts. Without knowledge of the password for an account, an adversary may opt to guess the password using a repetitive or iterative mechanism systematically. More details can be found [here](https://attack.mitre.org/techniques/T1110/001/). +Adversaries with no prior knowledge of legitimate credentials within the system or environment may guess passwords to attempt access to accounts. Without knowledge of the password for an account, an adversary may opt to guess the password using a repetitive or iterative mechanism systematically. More details can be found https://attack.mitre.org/techniques/T1110/001/. This rule identifies potential password guessing/brute force activity from a single address against an account that contains the `admin` pattern on its name, which is likely a highly privileged account. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps @@ -97,6 +97,20 @@ This rule identifies potential password guessing/brute force activity from a sin - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/process-activity-via-compiled-html-file.asciidoc b/docs/detections/prebuilt-rules/rule-details/process-activity-via-compiled-html-file.asciidoc index b1af5f89fb..174293ddf4 100644 --- a/docs/detections/prebuilt-rules/rule-details/process-activity-via-compiled-html-file.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/process-activity-via-compiled-html-file.asciidoc @@ -57,7 +57,7 @@ CHM (Compiled HTML) files are a format for delivering online help files on Windo When users double-click CHM files, the HTML Help executable program (`hh.exe`) will execute them. `hh.exe` also can be used to execute code embedded in those files, PowerShell scripts, and executables. This makes it useful for attackers not only to proxy the execution of malicious payloads via a signed binary that could bypass security controls, but also to gain initial access to environments via social engineering methods. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps @@ -106,6 +106,20 @@ When users double-click CHM files, the HTML Help executable program (`hh.exe`) w - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/process-capability-enumeration.asciidoc b/docs/detections/prebuilt-rules/rule-details/process-capability-enumeration.asciidoc index f02ecd29ab..165fa5e6ee 100644 --- a/docs/detections/prebuilt-rules/rule-details/process-capability-enumeration.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/process-capability-enumeration.asciidoc @@ -38,6 +38,38 @@ Identifies recursive process capability enumeration of the entire filesystem thr *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/process-creation-via-secondary-logon.asciidoc b/docs/detections/prebuilt-rules/rule-details/process-creation-via-secondary-logon.asciidoc index 27ab953118..8ebd1988b7 100644 --- a/docs/detections/prebuilt-rules/rule-details/process-creation-via-secondary-logon.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/process-creation-via-secondary-logon.asciidoc @@ -41,6 +41,22 @@ Identifies process creation with alternate credentials. Adversaries may create a *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +Audit events 4624 and 4688 are needed to trigger this rule. + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/process-execution-from-an-unusual-directory.asciidoc b/docs/detections/prebuilt-rules/rule-details/process-execution-from-an-unusual-directory.asciidoc index 625e28e4d2..108b44609f 100644 --- a/docs/detections/prebuilt-rules/rule-details/process-execution-from-an-unusual-directory.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/process-execution-from-an-unusual-directory.asciidoc @@ -54,7 +54,7 @@ Identifies process execution from suspicious default Windows directories. This i This rule identifies processes that are executed from suspicious default Windows directories. Adversaries may abuse this technique by planting malware in trusted paths, making it difficult for security analysts to discern if their activities are malicious or take advantage of exceptions that may apply to these paths. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. ### Possible investigation steps @@ -104,6 +104,20 @@ This rule identifies processes that are executed from suspicious default Windows ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/process-started-from-process-id-pid-file.asciidoc b/docs/detections/prebuilt-rules/rule-details/process-started-from-process-id-pid-file.asciidoc index dd588fad25..bf81fe4cd1 100644 --- a/docs/detections/prebuilt-rules/rule-details/process-started-from-process-id-pid-file.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/process-started-from-process-id-pid-file.asciidoc @@ -60,6 +60,38 @@ Detection alerts from this rule indicate a process spawned from an executable ma - Examine the reputation of the SHA256 hash from the PID file in a database like VirusTotal to identify additional pivots and artifacts for investigation. +---------------------------------- + +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/process-termination-followed-by-deletion.asciidoc b/docs/detections/prebuilt-rules/rule-details/process-termination-followed-by-deletion.asciidoc index 73fe43a1d1..6f804bf519 100644 --- a/docs/detections/prebuilt-rules/rule-details/process-termination-followed-by-deletion.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/process-termination-followed-by-deletion.asciidoc @@ -53,7 +53,7 @@ Identifies a process termination event quickly followed by the deletion of its e This rule identifies an unsigned process termination event quickly followed by the deletion of its executable file. Attackers can delete programs after their execution in an attempt to cover their tracks in a host. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps diff --git a/docs/detections/prebuilt-rules/rule-details/program-files-directory-masquerading.asciidoc b/docs/detections/prebuilt-rules/rule-details/program-files-directory-masquerading.asciidoc index 69a69b43e7..cd4f57f211 100644 --- a/docs/detections/prebuilt-rules/rule-details/program-files-directory-masquerading.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/program-files-directory-masquerading.asciidoc @@ -42,6 +42,20 @@ Identifies execution from a directory masquerading as the Windows Program Files *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/prompt-for-credentials-with-osascript.asciidoc b/docs/detections/prebuilt-rules/rule-details/prompt-for-credentials-with-osascript.asciidoc index c949d35951..060ca5585a 100644 --- a/docs/detections/prebuilt-rules/rule-details/prompt-for-credentials-with-osascript.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/prompt-for-credentials-with-osascript.asciidoc @@ -41,6 +41,38 @@ Identifies the use of osascript to execute scripts via standard input that may p *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### The following steps should be executed in order to add the Elastic Defend integration on a macOS 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, for MacOS it is recommended to select "Traditional Endpoints". +- 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/proxychains-activity.asciidoc b/docs/detections/prebuilt-rules/rule-details/proxychains-activity.asciidoc index 23e2b07dc9..678021eda7 100644 --- a/docs/detections/prebuilt-rules/rule-details/proxychains-activity.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/proxychains-activity.asciidoc @@ -55,8 +55,8 @@ Attackers can leverage `proxychains` to obfuscate their origin and bypass networ This rule looks for processes spawned through `proxychains` by analyzing `proxychains` process execution. > **Note**: -> This investigation guide uses the {security-guide}/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. -> This investigation guide uses {security-guide}/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. #### Possible investigation steps diff --git a/docs/detections/prebuilt-rules/rule-details/python-script-execution-via-command-line.asciidoc b/docs/detections/prebuilt-rules/rule-details/python-script-execution-via-command-line.asciidoc index 5ecdfcaade..fd3056edda 100644 --- a/docs/detections/prebuilt-rules/rule-details/python-script-execution-via-command-line.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/python-script-execution-via-command-line.asciidoc @@ -41,6 +41,20 @@ Identifies when a Python script is executed using command line input and imports *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query 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 967e0e6785..5eb3b5b0bc 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 @@ -95,8 +95,16 @@ Detection alerts from this rule indicate a rare and unusual error code that was - 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 [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS. +- Implement security best practices https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/ 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 + + +[source, markdown] +---------------------------------- +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/rdp-enabled-via-registry.asciidoc b/docs/detections/prebuilt-rules/rule-details/rdp-enabled-via-registry.asciidoc index a93db02014..c13dfc8c75 100644 --- a/docs/detections/prebuilt-rules/rule-details/rdp-enabled-via-registry.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/rdp-enabled-via-registry.asciidoc @@ -86,6 +86,20 @@ This rule detects modification of the fDenyTSConnections registry key to the val - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/registry-persistence-via-appcert-dll.asciidoc b/docs/detections/prebuilt-rules/rule-details/registry-persistence-via-appcert-dll.asciidoc index 1795194677..caa9da625b 100644 --- a/docs/detections/prebuilt-rules/rule-details/registry-persistence-via-appcert-dll.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/registry-persistence-via-appcert-dll.asciidoc @@ -43,6 +43,20 @@ Detects attempts to maintain persistence by creating registry keys using AppCert *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/registry-persistence-via-appinit-dll.asciidoc b/docs/detections/prebuilt-rules/rule-details/registry-persistence-via-appinit-dll.asciidoc index 6a5e97f0df..8a396b9ab1 100644 --- a/docs/detections/prebuilt-rules/rule-details/registry-persistence-via-appinit-dll.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/registry-persistence-via-appinit-dll.asciidoc @@ -60,7 +60,7 @@ Attackers who add those DLLs to the registry locations can execute code with ele This rule identifies modifications on the AppInit registry keys. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps @@ -103,6 +103,20 @@ This rule identifies modifications on the AppInit registry keys. - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/remote-desktop-enabled-in-windows-firewall-by-netsh.asciidoc b/docs/detections/prebuilt-rules/rule-details/remote-desktop-enabled-in-windows-firewall-by-netsh.asciidoc index 0179b656f0..2ee233c290 100644 --- a/docs/detections/prebuilt-rules/rule-details/remote-desktop-enabled-in-windows-firewall-by-netsh.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/remote-desktop-enabled-in-windows-firewall-by-netsh.asciidoc @@ -86,6 +86,20 @@ This rule detects the creation of a Windows Firewall inbound rule that would all - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/remote-execution-via-file-shares.asciidoc b/docs/detections/prebuilt-rules/rule-details/remote-execution-via-file-shares.asciidoc index 782cd35c79..9086a6ea01 100644 --- a/docs/detections/prebuilt-rules/rule-details/remote-execution-via-file-shares.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/remote-execution-via-file-shares.asciidoc @@ -54,7 +54,7 @@ Identifies the execution of a file that was created by the virtual system proces Adversaries can use network shares to host tooling to support the compromise of other hosts in the environment. These tools can include discovery utilities, credential dumpers, malware, etc. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps diff --git a/docs/detections/prebuilt-rules/rule-details/remote-file-copy-to-a-hidden-share.asciidoc b/docs/detections/prebuilt-rules/rule-details/remote-file-copy-to-a-hidden-share.asciidoc index e473e18c79..a78fdfe510 100644 --- a/docs/detections/prebuilt-rules/rule-details/remote-file-copy-to-a-hidden-share.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/remote-file-copy-to-a-hidden-share.asciidoc @@ -42,6 +42,20 @@ Identifies a remote file copy attempt to a hidden network share. This may indica *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/remote-file-copy-via-teamviewer.asciidoc b/docs/detections/prebuilt-rules/rule-details/remote-file-copy-via-teamviewer.asciidoc index d1d1984118..0f647d058c 100644 --- a/docs/detections/prebuilt-rules/rule-details/remote-file-copy-via-teamviewer.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/remote-file-copy-via-teamviewer.asciidoc @@ -59,7 +59,7 @@ Attackers commonly transfer tooling or malware from external systems into a comp TeamViewer is a remote access and remote control tool used by helpdesks and system administrators to perform various support activities. It is also frequently used by attackers and scammers to deploy malware interactively and other malicious activities. This rule looks for the TeamViewer process creating files with suspicious extensions. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps @@ -102,6 +102,20 @@ TeamViewer is a remote access and remote control tool used by helpdesks and syst +---------------------------------- + +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/remote-file-download-via-desktopimgdownldr-utility.asciidoc b/docs/detections/prebuilt-rules/rule-details/remote-file-download-via-desktopimgdownldr-utility.asciidoc index f63de4f3a6..a1e0e59333 100644 --- a/docs/detections/prebuilt-rules/rule-details/remote-file-download-via-desktopimgdownldr-utility.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/remote-file-download-via-desktopimgdownldr-utility.asciidoc @@ -60,8 +60,8 @@ Attackers commonly transfer tooling or malware from external systems into a comp The `Desktopimgdownldr.exe` utility is used to to configure lockscreen/desktop image, and can be abused with the `lockscreenurl` argument to download remote files and tools, this rule looks for this behavior. > **Note**: -> This investigation guide uses the {security-guide}/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. -> This investigation guide uses the {security-guide}/security/master/interactive-investigation-guides.html[Investigate Markdown Plugin] introduced in Elastic Stack version 8.8.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/interactive-investigation-guides.html introduced in Elastic Stack version 8.8.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps @@ -111,6 +111,20 @@ The `Desktopimgdownldr.exe` utility is used to to configure lockscreen/desktop i +---------------------------------- + +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/remote-file-download-via-mpcmdrun.asciidoc b/docs/detections/prebuilt-rules/rule-details/remote-file-download-via-mpcmdrun.asciidoc index 0dacdfb8e4..5d4c964291 100644 --- a/docs/detections/prebuilt-rules/rule-details/remote-file-download-via-mpcmdrun.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/remote-file-download-via-mpcmdrun.asciidoc @@ -61,8 +61,8 @@ Attackers commonly transfer tooling or malware from external systems into a comp The `MpCmdRun.exe` is a command-line tool part of Windows Defender and is used to manage various Microsoft Windows Defender Antivirus settings and perform certain tasks. It can also be abused by attackers to download remote files, including malware and offensive tooling. This rule looks for the patterns used to perform downloads using the utility. > **Note**: -> This investigation guide uses the {security-guide}/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. -> This investigation guide uses the {security-guide}/security/master/interactive-investigation-guides.html[Investigate Markdown Plugin] introduced in Elastic Stack version 8.8.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/interactive-investigation-guides.html introduced in Elastic Stack version 8.8.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps @@ -109,6 +109,20 @@ The `MpCmdRun.exe` is a command-line tool part of Windows Defender and is used t - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/remote-file-download-via-powershell.asciidoc b/docs/detections/prebuilt-rules/rule-details/remote-file-download-via-powershell.asciidoc index 0826d11221..8a499bcd94 100644 --- a/docs/detections/prebuilt-rules/rule-details/remote-file-download-via-powershell.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/remote-file-download-via-powershell.asciidoc @@ -53,8 +53,8 @@ Attackers commonly transfer tooling or malware from external systems into a comp PowerShell is one of system administrators' main tools for automation, report routines, and other tasks. This makes it available for use in various environments and creates an attractive way for attackers to execute code and perform actions. This rule correlates network and file events to detect downloads of executable and script files performed using PowerShell. > **Note**: -> This investigation guide uses the {security-guide}/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. -> This investigation guide uses the {security-guide}/security/master/interactive-investigation-guides.html[Investigate Markdown Plugin] introduced in Elastic Stack version 8.8.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/interactive-investigation-guides.html introduced in Elastic Stack version 8.8.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps diff --git a/docs/detections/prebuilt-rules/rule-details/remote-file-download-via-script-interpreter.asciidoc b/docs/detections/prebuilt-rules/rule-details/remote-file-download-via-script-interpreter.asciidoc index b906c4992e..c02b27900a 100644 --- a/docs/detections/prebuilt-rules/rule-details/remote-file-download-via-script-interpreter.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/remote-file-download-via-script-interpreter.asciidoc @@ -58,7 +58,7 @@ Attackers commonly use WSH scripts as their initial access method, acting like d This rule looks for DLLs and executables downloaded using `cscript.exe` or `wscript.exe`. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps diff --git a/docs/detections/prebuilt-rules/rule-details/remote-scheduled-task-creation-via-rpc.asciidoc b/docs/detections/prebuilt-rules/rule-details/remote-scheduled-task-creation-via-rpc.asciidoc index f89d927ea7..eece0fa9ae 100644 --- a/docs/detections/prebuilt-rules/rule-details/remote-scheduled-task-creation-via-rpc.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/remote-scheduled-task-creation-via-rpc.asciidoc @@ -48,7 +48,7 @@ Identifies scheduled task creation from a remote source. This could be indicativ ### Investigating Remote Scheduled Task Creation -[Scheduled tasks](https://docs.microsoft.com/en-us/windows/win32/taskschd/about-the-task-scheduler) are a great mechanism for persistence and program execution. These features can be used remotely for a variety of legitimate reasons, but at the same time used by malware and adversaries. When investigating scheduled tasks that were set up remotely, one of the first steps should be to determine the original intent behind the configuration and to verify if the activity is tied to benign behavior such as software installation or any kind of network administrator work. One objective for these alerts is to understand the configured action within the scheduled task. This is captured within the registry event data for this rule and can be base64 decoded to view the value. +https://docs.microsoft.com/en-us/windows/win32/taskschd/about-the-task-scheduler are a great mechanism for persistence and program execution. These features can be used remotely for a variety of legitimate reasons, but at the same time used by malware and adversaries. When investigating scheduled tasks that were set up remotely, one of the first steps should be to determine the original intent behind the configuration and to verify if the activity is tied to benign behavior such as software installation or any kind of network administrator work. One objective for these alerts is to understand the configured action within the scheduled task. This is captured within the registry event data for this rule and can be base64 decoded to view the value. #### Possible investigation steps diff --git a/docs/detections/prebuilt-rules/rule-details/remote-scheduled-task-creation.asciidoc b/docs/detections/prebuilt-rules/rule-details/remote-scheduled-task-creation.asciidoc index 4ad40300ad..301421800a 100644 --- a/docs/detections/prebuilt-rules/rule-details/remote-scheduled-task-creation.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/remote-scheduled-task-creation.asciidoc @@ -50,7 +50,7 @@ Identifies remote scheduled task creations on a target host. This could be indic ### Investigating Remote Scheduled Task Creation -[Scheduled tasks](https://docs.microsoft.com/en-us/windows/win32/taskschd/about-the-task-scheduler) are a great mechanism for persistence and program execution. These features can be used remotely for a variety of legitimate reasons, but at the same time used by malware and adversaries. When investigating scheduled tasks that were set up remotely, one of the first steps should be to determine the original intent behind the configuration and to verify if the activity is tied to benign behavior such as software installation or any kind of network administrator work. One objective for these alerts is to understand the configured action within the scheduled task. This is captured within the registry event data for this rule and can be base64 decoded to view the value. +https://docs.microsoft.com/en-us/windows/win32/taskschd/about-the-task-scheduler are a great mechanism for persistence and program execution. These features can be used remotely for a variety of legitimate reasons, but at the same time used by malware and adversaries. When investigating scheduled tasks that were set up remotely, one of the first steps should be to determine the original intent behind the configuration and to verify if the activity is tied to benign behavior such as software installation or any kind of network administrator work. One objective for these alerts is to understand the configured action within the scheduled task. This is captured within the registry event data for this rule and can be base64 decoded to view the value. #### Possible investigation steps diff --git a/docs/detections/prebuilt-rules/rule-details/remote-ssh-login-enabled-via-systemsetup-command.asciidoc b/docs/detections/prebuilt-rules/rule-details/remote-ssh-login-enabled-via-systemsetup-command.asciidoc index ed7103c171..e031c00d31 100644 --- a/docs/detections/prebuilt-rules/rule-details/remote-ssh-login-enabled-via-systemsetup-command.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/remote-ssh-login-enabled-via-systemsetup-command.asciidoc @@ -42,6 +42,38 @@ Detects use of the systemsetup command to enable remote SSH Login. *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### The following steps should be executed in order to add the Elastic Defend integration on a macOS 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, for MacOS it is recommended to select "Traditional Endpoints". +- 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/remote-system-discovery-commands.asciidoc b/docs/detections/prebuilt-rules/rule-details/remote-system-discovery-commands.asciidoc index 15072162d2..d0627c93cb 100644 --- a/docs/detections/prebuilt-rules/rule-details/remote-system-discovery-commands.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/remote-system-discovery-commands.asciidoc @@ -78,6 +78,21 @@ This rule looks for the execution of the `arp` or `nbstat` utilities to enumerat - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/remotely-started-services-via-rpc.asciidoc b/docs/detections/prebuilt-rules/rule-details/remotely-started-services-via-rpc.asciidoc index df1cb08029..54bceb3a03 100644 --- a/docs/detections/prebuilt-rules/rule-details/remotely-started-services-via-rpc.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/remotely-started-services-via-rpc.asciidoc @@ -57,7 +57,7 @@ The Service Control Manager Remote Protocol is a client/server protocol used for This rule detects the remote creation or start of a service by correlating a `services.exe` network connection and the spawn of a child process. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps diff --git a/docs/detections/prebuilt-rules/rule-details/renamed-autoit-scripts-interpreter.asciidoc b/docs/detections/prebuilt-rules/rule-details/renamed-autoit-scripts-interpreter.asciidoc index f027095e04..8798a28ea9 100644 --- a/docs/detections/prebuilt-rules/rule-details/renamed-autoit-scripts-interpreter.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/renamed-autoit-scripts-interpreter.asciidoc @@ -59,7 +59,7 @@ AutoIt is a scripting language and tool for automating tasks on Microsoft Window This rule checks for renamed instances of AutoIt, which can indicate an attempt of evading detections, application allowlists, and other security protections. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps @@ -99,6 +99,20 @@ This rule checks for renamed instances of AutoIt, which can indicate an attempt - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/renamed-utility-executed-with-short-program-name.asciidoc b/docs/detections/prebuilt-rules/rule-details/renamed-utility-executed-with-short-program-name.asciidoc index c9458514d2..2dc2eb7dff 100644 --- a/docs/detections/prebuilt-rules/rule-details/renamed-utility-executed-with-short-program-name.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/renamed-utility-executed-with-short-program-name.asciidoc @@ -55,7 +55,7 @@ Identifies the execution of a process with a single character process name, diff Identifies the execution of a process with a single character process name, differing from the original file name. This is often done by adversaries while staging, executing temporary utilities, or trying to bypass security detections based on the process name. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps diff --git a/docs/detections/prebuilt-rules/rule-details/root-network-connection-via-gdb-cap-sys-ptrace.asciidoc b/docs/detections/prebuilt-rules/rule-details/root-network-connection-via-gdb-cap-sys-ptrace.asciidoc index f25e12ef4b..8220207c7c 100644 --- a/docs/detections/prebuilt-rules/rule-details/root-network-connection-via-gdb-cap-sys-ptrace.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/root-network-connection-via-gdb-cap-sys-ptrace.asciidoc @@ -40,6 +40,38 @@ Identifies instances where GDB (granted the CAP_SYS_PTRACE capability) is execut *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/scheduled-task-execution-at-scale-via-gpo.asciidoc b/docs/detections/prebuilt-rules/rule-details/scheduled-task-execution-at-scale-via-gpo.asciidoc index fd3efb8377..3bc1e0ffc2 100644 --- a/docs/detections/prebuilt-rules/rule-details/scheduled-task-execution-at-scale-via-gpo.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/scheduled-task-execution-at-scale-via-gpo.asciidoc @@ -86,6 +86,42 @@ Group Policy Objects (GPOs) can be used by attackers to execute scheduled tasks - 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 + + +[source, markdown] +---------------------------------- + +The 'Audit Detailed File Share' audit policy must be configured (Success Failure). +Steps to implement the logging policy with with Advanced Audit Configuration: + +``` +Computer Configuration > +Policies > +Windows Settings > +Security Settings > +Advanced Audit Policies Configuration > +Audit Policies > +Object Access > +Audit Detailed File Share (Success,Failure) +``` + +The 'Audit Directory Service Changes' audit policy must be configured (Success Failure). +Steps to implement the logging policy with 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) +``` + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/scheduled-tasks-at-command-enabled.asciidoc b/docs/detections/prebuilt-rules/rule-details/scheduled-tasks-at-command-enabled.asciidoc index 7d08304080..8c73f9b9ff 100644 --- a/docs/detections/prebuilt-rules/rule-details/scheduled-tasks-at-command-enabled.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/scheduled-tasks-at-command-enabled.asciidoc @@ -45,6 +45,20 @@ Identifies attempts to enable the Windows scheduled tasks AT command via the reg *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/screensaver-plist-file-modified-by-unexpected-process.asciidoc b/docs/detections/prebuilt-rules/rule-details/screensaver-plist-file-modified-by-unexpected-process.asciidoc index 1859770477..1ad265f7aa 100644 --- a/docs/detections/prebuilt-rules/rule-details/screensaver-plist-file-modified-by-unexpected-process.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/screensaver-plist-file-modified-by-unexpected-process.asciidoc @@ -53,6 +53,38 @@ Identifies when a screensaver plist file is modified by an unexpected process. A - Identify if any suspicious or known malicious screensaver (.saver) files were recently written to or modified on the host +---------------------------------- + +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### The following steps should be executed in order to add the Elastic Defend integration on a macOS 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, for MacOS it is recommended to select "Traditional Endpoints". +- 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. +- 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. +- 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. + + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/searching-for-saved-credentials-via-vaultcmd.asciidoc b/docs/detections/prebuilt-rules/rule-details/searching-for-saved-credentials-via-vaultcmd.asciidoc index 691a95cee3..6c56d3345b 100644 --- a/docs/detections/prebuilt-rules/rule-details/searching-for-saved-credentials-via-vaultcmd.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/searching-for-saved-credentials-via-vaultcmd.asciidoc @@ -46,6 +46,20 @@ Windows Credential Manager allows you to create, view, or delete saved credentia *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/security-software-discovery-using-wmic.asciidoc b/docs/detections/prebuilt-rules/rule-details/security-software-discovery-using-wmic.asciidoc index 98163f544c..dd320fce36 100644 --- a/docs/detections/prebuilt-rules/rule-details/security-software-discovery-using-wmic.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/security-software-discovery-using-wmic.asciidoc @@ -78,6 +78,21 @@ This rule looks for the execution of the `wmic` utility with arguments compatibl - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/security-software-discovery-via-grep.asciidoc b/docs/detections/prebuilt-rules/rule-details/security-software-discovery-via-grep.asciidoc index a611299157..892ca5f371 100644 --- a/docs/detections/prebuilt-rules/rule-details/security-software-discovery-via-grep.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/security-software-discovery-via-grep.asciidoc @@ -77,6 +77,21 @@ This rule looks for the execution of the `grep` utility with arguments compatibl - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/sedebugprivilege-enabled-by-a-suspicious-process.asciidoc b/docs/detections/prebuilt-rules/rule-details/sedebugprivilege-enabled-by-a-suspicious-process.asciidoc index 61aa190986..600173b1c2 100644 --- a/docs/detections/prebuilt-rules/rule-details/sedebugprivilege-enabled-by-a-suspicious-process.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/sedebugprivilege-enabled-by-a-suspicious-process.asciidoc @@ -42,6 +42,29 @@ Identifies the creation of a process running as SYSTEM and impersonating a Windo *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +Windows Event 4703 logs Token Privileges changes and need to be configured (Enable). + +Steps to implement the logging policy with with Advanced Audit Configuration: + +``` +Computer Configuration > +Policies > +Windows Settings > +Security Settings > +Advanced Audit Policies Configuration > +Audit Policies > +Detailed Tracking > +Token Right Adjusted Events (Success) +``` + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/segfault-detected.asciidoc b/docs/detections/prebuilt-rules/rule-details/segfault-detected.asciidoc index 1eb35385ed..b9394b0b12 100644 --- a/docs/detections/prebuilt-rules/rule-details/segfault-detected.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/segfault-detected.asciidoc @@ -38,6 +38,37 @@ Monitors kernel logs for segfault messages. A segfault, or segmentation fault, i *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- +## Setup + +This rule requires data coming in from one of the following integrations: +- Filebeat + +### Filebeat Setup + +Filebeat is a lightweight shipper for forwarding and centralizing log data. Installed as an agent on your servers, Filebeat monitors the log files or locations that you specify, collects log events, and forwards them either to Elasticsearch or Logstash for indexing. + +#### The following steps should be executed in order to add the Filebeat for the Linux System: + +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/filebeat/current/setup-repositories.html. +- To run Filebeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/running-on-docker.html. +- To run Filebeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/running-on-kubernetes.html. +- For quick start information for Filebeat refer to the https://www.elastic.co/guide/en/beats/filebeat/8.11/filebeat-installation-configuration.html. +- For complete Setup and Run Filebeat information refer to the https://www.elastic.co/guide/en/beats/filebeat/current/setting-up-and-running.html. + +#### Rule Specific Setup Note + +- This rule requires the Filebeat System Module to be enabled. +- The system module collects and parses logs created by the system logging service of common Unix/Linux based distributions. +- To run the system module of Filebeat on Linux follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-system.html. + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/sensitive-files-compression.asciidoc b/docs/detections/prebuilt-rules/rule-details/sensitive-files-compression.asciidoc index 75fedf6dcb..fea56e1b9a 100644 --- a/docs/detections/prebuilt-rules/rule-details/sensitive-files-compression.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/sensitive-files-compression.asciidoc @@ -44,6 +44,52 @@ Identifies the use of a compression utility to collect known files containing se *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Auditbeat + + +### 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. + +#### 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. +- We suggest to select "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. +- 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. + +### Auditbeat Setup +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + +#### The following steps should be executed in order to add the Auditbeat on a Linux System: +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/sensitive-privilege-seenabledelegationprivilege-assigned-to-a-user.asciidoc b/docs/detections/prebuilt-rules/rule-details/sensitive-privilege-seenabledelegationprivilege-assigned-to-a-user.asciidoc index 332fa564e5..becaf2910f 100644 --- a/docs/detections/prebuilt-rules/rule-details/sensitive-privilege-seenabledelegationprivilege-assigned-to-a-user.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/sensitive-privilege-seenabledelegationprivilege-assigned-to-a-user.asciidoc @@ -89,6 +89,27 @@ It is critical to control the assignment of this privilege. A user with this pri - 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 + + +[source, markdown] +---------------------------------- + +The 'Audit Authorization Policy Change' logging policy must be configured for (Success, Failure). +Steps to implement the logging policy with Advanced Audit Configuration: + +``` +Computer Configuration > +Windows Settings > +Security Settings > +Advanced Audit Policy Configuration > +Audit Policies > +Policy Change > +Audit Authorization Policy Change (Success,Failure) +``` + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/service-control-spawned-via-script-interpreter.asciidoc b/docs/detections/prebuilt-rules/rule-details/service-control-spawned-via-script-interpreter.asciidoc index 8372f2b102..487780265e 100644 --- a/docs/detections/prebuilt-rules/rule-details/service-control-spawned-via-script-interpreter.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/service-control-spawned-via-script-interpreter.asciidoc @@ -60,7 +60,7 @@ Windows services are background processes that run with SYSTEM privileges and pr The `sc.exe` command line utility is used to manage and control Windows services on a local or remote computer. Attackers may use `sc.exe` to create, modify, and start services to elevate their privileges from administrator to SYSTEM. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps diff --git a/docs/detections/prebuilt-rules/rule-details/setcap-setuid-setgid-capability-set.asciidoc b/docs/detections/prebuilt-rules/rule-details/setcap-setuid-setgid-capability-set.asciidoc index bb9b025d94..a5670b1293 100644 --- a/docs/detections/prebuilt-rules/rule-details/setcap-setuid-setgid-capability-set.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/setcap-setuid-setgid-capability-set.asciidoc @@ -54,8 +54,8 @@ Threat actors can exploit these attributes to achieve persistence by creating ma This rule monitors for the addition of the cap_setuid+ep or cap_setgid+ep capabilities via setcap. > **Note**: -> This investigation guide uses the {security-guide}/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. -> This investigation guide uses {security-guide}/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. #### Possible Investigation Steps @@ -103,6 +103,38 @@ This rule monitors for the addition of the cap_setuid+ep or cap_setgid+ep capabi - Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. - Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). +---------------------------------- + +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/shared-object-created-or-changed-by-previously-unknown-process.asciidoc b/docs/detections/prebuilt-rules/rule-details/shared-object-created-or-changed-by-previously-unknown-process.asciidoc index 4a9ed54bbc..4b88659768 100644 --- a/docs/detections/prebuilt-rules/rule-details/shared-object-created-or-changed-by-previously-unknown-process.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/shared-object-created-or-changed-by-previously-unknown-process.asciidoc @@ -58,8 +58,8 @@ Malicious actors can leverage shared object files to execute unauthorized code, This rule monitors the creation of shared object files by previously unknown processes through the usage of the new terms rule type. > **Note**: -> This investigation guide uses the {security-guide}/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. -> This investigation guide uses {security-guide}/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. #### Possible Investigation Steps @@ -109,6 +109,38 @@ This rule monitors the creation of shared object files by previously unknown pro - Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. - Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). +---------------------------------- + +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/sharepoint-malware-file-upload.asciidoc b/docs/detections/prebuilt-rules/rule-details/sharepoint-malware-file-upload.asciidoc index fddf0b5c4b..ec7af3b3fe 100644 --- a/docs/detections/prebuilt-rules/rule-details/sharepoint-malware-file-upload.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/sharepoint-malware-file-upload.asciidoc @@ -47,6 +47,14 @@ Identifies the occurence of files uploaded to SharePoint being detected as Malwa ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/shell-execution-via-apple-scripting.asciidoc b/docs/detections/prebuilt-rules/rule-details/shell-execution-via-apple-scripting.asciidoc index f9a1e48a38..3935748beb 100644 --- a/docs/detections/prebuilt-rules/rule-details/shell-execution-via-apple-scripting.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/shell-execution-via-apple-scripting.asciidoc @@ -41,6 +41,38 @@ Identifies the execution of the shell process (sh) via scripting (JXA or AppleSc *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### The following steps should be executed in order to add the Elastic Defend integration on a macOS 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, for MacOS it is recommended to select "Traditional Endpoints". +- 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/signed-proxy-execution-via-ms-work-folders.asciidoc b/docs/detections/prebuilt-rules/rule-details/signed-proxy-execution-via-ms-work-folders.asciidoc index 52538acb78..caefe1b0b3 100644 --- a/docs/detections/prebuilt-rules/rule-details/signed-proxy-execution-via-ms-work-folders.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/signed-proxy-execution-via-ms-work-folders.asciidoc @@ -84,6 +84,20 @@ disk from a separate binary. - Confirm with the user whether this was expected or not, and reset their password. +---------------------------------- + +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/softwareupdate-preferences-modification.asciidoc b/docs/detections/prebuilt-rules/rule-details/softwareupdate-preferences-modification.asciidoc index cab0bea6b7..133438bc88 100644 --- a/docs/detections/prebuilt-rules/rule-details/softwareupdate-preferences-modification.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/softwareupdate-preferences-modification.asciidoc @@ -40,6 +40,38 @@ Identifies changes to the SoftwareUpdate preferences using the built-in defaults *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### The following steps should be executed in order to add the Elastic Defend integration on a macOS 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, for MacOS it is recommended to select "Traditional Endpoints". +- 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/solarwinds-process-disabling-services-via-registry.asciidoc b/docs/detections/prebuilt-rules/rule-details/solarwinds-process-disabling-services-via-registry.asciidoc index e1c63c49d5..2f07148a3a 100644 --- a/docs/detections/prebuilt-rules/rule-details/solarwinds-process-disabling-services-via-registry.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/solarwinds-process-disabling-services-via-registry.asciidoc @@ -45,6 +45,20 @@ Identifies a SolarWinds binary modifying the start type of a service to be disab *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query 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 ade88a91ce..daa3ee8c2d 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 @@ -93,8 +93,16 @@ This rule uses a machine learning job to detect a significant spike in the rate - 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 [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS. +- Implement security best practices https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/ 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 + + +[source, markdown] +---------------------------------- +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/spike-in-bytes-sent-to-an-external-device-via-airdrop.asciidoc b/docs/detections/prebuilt-rules/rule-details/spike-in-bytes-sent-to-an-external-device-via-airdrop.asciidoc index 34a9652d9b..88541f148f 100644 --- a/docs/detections/prebuilt-rules/rule-details/spike-in-bytes-sent-to-an-external-device-via-airdrop.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/spike-in-bytes-sent-to-an-external-device-via-airdrop.asciidoc @@ -39,6 +39,36 @@ A machine learning job has detected high bytes of data written to an external de *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- +The rule requires the Data Exfiltration Detection integration assets to be installed, as well as network and file events collected by integrations such as Elastic Defend and Network Packet Capture (for network events only). + +### Data Exfiltration Detection Setup +The Data Exfiltration Detection integration detects data exfiltration activity by identifying abnormalities in network and file events. Anomalies are detected using Elastic's Anomaly Detection feature. + +#### Prerequisite Requirements: +- Fleet is required for Data Exfiltration Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html. +- File events collected by the Elastic Defend integration. +- To install Elastic Defend, refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html. + +#### The following steps should be executed to install assets associated with the Data Exfiltration Detection integration: +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Data Exfiltration Detection and select the integration to see more details about it. +- Under Settings, click Install Data Exfiltration Detection assets and follow the prompts to install the assets. + +#### Anomaly Detection Setup +Before you can enable rules for Data Exfiltration Detection, you'll need to enable the corresponding Anomaly Detection jobs. +- Go to the Kibana homepage. Under Analytics, click Machine Learning. +- Under Anomaly Detection, click Jobs, and then click "Create job". Select the Data View containing your file events. For example, this would be `logs-endpoint.events.*` if you used Elastic Defend to collect events. +- If the selected Data View contains events that match the query in https://github.com/elastic/integrations/blob/main/packages/ded/kibana/ml_module/ded-ml.json configuration file, you will see a card for Data Exfiltration Detection under "Use preconfigured jobs". +- Keep the default settings and click "Create jobs" to start the anomaly detection jobs and datafeeds. + +---------------------------------- + *Framework*: MITRE ATT&CK^TM^ * Tactic: diff --git a/docs/detections/prebuilt-rules/rule-details/spike-in-bytes-sent-to-an-external-device.asciidoc b/docs/detections/prebuilt-rules/rule-details/spike-in-bytes-sent-to-an-external-device.asciidoc index 7fa5f7b2ea..c9e326abce 100644 --- a/docs/detections/prebuilt-rules/rule-details/spike-in-bytes-sent-to-an-external-device.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/spike-in-bytes-sent-to-an-external-device.asciidoc @@ -39,6 +39,36 @@ A machine learning job has detected high bytes of data written to an external de *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- +The rule requires the Data Exfiltration Detection integration assets to be installed, as well as network and file events collected by integrations such as Elastic Defend and Network Packet Capture (for network events only). + +### Data Exfiltration Detection Setup +The Data Exfiltration Detection integration detects data exfiltration activity by identifying abnormalities in network and file events. Anomalies are detected using Elastic's Anomaly Detection feature. + +#### Prerequisite Requirements: +- Fleet is required for Data Exfiltration Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html. +- File events collected by the Elastic Defend integration. +- To install Elastic Defend, refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html. + +#### The following steps should be executed to install assets associated with the Data Exfiltration Detection integration: +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Data Exfiltration Detection and select the integration to see more details about it. +- Under Settings, click Install Data Exfiltration Detection assets and follow the prompts to install the assets. + +#### Anomaly Detection Setup +Before you can enable rules for Data Exfiltration Detection, you'll need to enable the corresponding Anomaly Detection jobs. +- Go to the Kibana homepage. Under Analytics, click Machine Learning. +- Under Anomaly Detection, click Jobs, and then click "Create job". Select the Data View containing your file events. For example, this would be `logs-endpoint.events.*` if you used Elastic Defend to collect events. +- If the selected Data View contains events that match the query in https://github.com/elastic/integrations/blob/main/packages/ded/kibana/ml_module/ded-ml.json configuration file, you will see a card for Data Exfiltration Detection under "Use preconfigured jobs". +- Keep the default settings and click "Create jobs" to start the anomaly detection jobs and datafeeds. + +---------------------------------- + *Framework*: MITRE ATT&CK^TM^ * Tactic: diff --git a/docs/detections/prebuilt-rules/rule-details/spike-in-number-of-connections-made-from-a-source-ip.asciidoc b/docs/detections/prebuilt-rules/rule-details/spike-in-number-of-connections-made-from-a-source-ip.asciidoc index ba4ccd20c9..534886e3ca 100644 --- a/docs/detections/prebuilt-rules/rule-details/spike-in-number-of-connections-made-from-a-source-ip.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/spike-in-number-of-connections-made-from-a-source-ip.asciidoc @@ -40,6 +40,37 @@ A machine learning job has detected a high count of destination IPs establishing *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- +The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration. + +### Lateral Movement Detection Setup +The Lateral Movement Detection integration detects lateral movement activity by identifying abnormalities in file and Windows RDP events. Anomalies are detected using Elastic's Anomaly Detection feature. + +#### Prerequisite Requirements: +- Fleet is required for Lateral Movement Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html. +- Windows RDP process events collected by the https://docs.elastic.co/en/integrations/endpoint integration. +- To install Elastic Defend, refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html. + +#### The following steps should be executed to install assets associated with the Lateral Movement Detection integration: +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Lateral Movement Detection and select the integration to see more details about it. +- Under Settings, click Install Lateral Movement Detection assets and follow the prompts to install the assets. + +#### Anomaly Detection Setup +Before you can enable rules for Lateral Movement Detection, you'll need to enable the corresponding Anomaly Detection jobs. +- Before enabling the Anomaly Detection jobs, confirm that the Pivot Transform asset is installed and actively gathering data in the destination index `ml-rdp-lmd`. +- Go to the Kibana homepage. Under Analytics, click Machine Learning. +- Under Anomaly Detection, click Jobs, and then click "Create job". Select the Data View containing your transformed RDP process data i.e.`ml-rdp-lmd`. +- If the selected Data View contains events that match the query in https://github.com/elastic/integrations/blob/main/packages/lmd/kibana/ml_module/lmd-ml.json configuration file, you will see a card for Lateral Movement Detection under "Use preconfigured jobs". +- Keep the default settings and click "Create jobs" to start the anomaly detection jobs and datafeeds. + +---------------------------------- + *Framework*: MITRE ATT&CK^TM^ * Tactic: diff --git a/docs/detections/prebuilt-rules/rule-details/spike-in-number-of-connections-made-to-a-destination-ip.asciidoc b/docs/detections/prebuilt-rules/rule-details/spike-in-number-of-connections-made-to-a-destination-ip.asciidoc index cce626fb99..af71e2b585 100644 --- a/docs/detections/prebuilt-rules/rule-details/spike-in-number-of-connections-made-to-a-destination-ip.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/spike-in-number-of-connections-made-to-a-destination-ip.asciidoc @@ -40,6 +40,37 @@ A machine learning job has detected a high count of source IPs establishing an R *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- +The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration. + +### Lateral Movement Detection Setup +The Lateral Movement Detection integration detects lateral movement activity by identifying abnormalities in file and Windows RDP events. Anomalies are detected using Elastic's Anomaly Detection feature. + +#### Prerequisite Requirements: +- Fleet is required for Lateral Movement Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html. +- Windows RDP process events collected by the https://docs.elastic.co/en/integrations/endpoint integration. +- To install Elastic Defend, refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html. + +#### The following steps should be executed to install assets associated with the Lateral Movement Detection integration: +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Lateral Movement Detection and select the integration to see more details about it. +- Under Settings, click Install Lateral Movement Detection assets and follow the prompts to install the assets. + +#### Anomaly Detection Setup +Before you can enable rules for Lateral Movement Detection, you'll need to enable the corresponding Anomaly Detection jobs. +- Before enabling the Anomaly Detection jobs, confirm that the Pivot Transform asset is installed and actively gathering data in the destination index `ml-rdp-lmd`. +- Go to the Kibana homepage. Under Analytics, click Machine Learning. +- Under Anomaly Detection, click Jobs, and then click "Create job". Select the Data View containing your transformed RDP process data i.e.`ml-rdp-lmd`. +- If the selected Data View contains events that match the query in https://github.com/elastic/integrations/blob/main/packages/lmd/kibana/ml_module/lmd-ml.json configuration file, you will see a card for Lateral Movement Detection under "Use preconfigured jobs". +- Keep the default settings and click "Create jobs" to start the anomaly detection jobs and datafeeds. + +---------------------------------- + *Framework*: MITRE ATT&CK^TM^ * Tactic: diff --git a/docs/detections/prebuilt-rules/rule-details/spike-in-number-of-processes-in-an-rdp-session.asciidoc b/docs/detections/prebuilt-rules/rule-details/spike-in-number-of-processes-in-an-rdp-session.asciidoc index a9b050c27c..8f8a704001 100644 --- a/docs/detections/prebuilt-rules/rule-details/spike-in-number-of-processes-in-an-rdp-session.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/spike-in-number-of-processes-in-an-rdp-session.asciidoc @@ -40,6 +40,37 @@ A machine learning job has detected unusually high number of processes started i *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- +The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration. + +### Lateral Movement Detection Setup +The Lateral Movement Detection integration detects lateral movement activity by identifying abnormalities in file and Windows RDP events. Anomalies are detected using Elastic's Anomaly Detection feature. + +#### Prerequisite Requirements: +- Fleet is required for Lateral Movement Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html. +- Windows RDP process events collected by the https://docs.elastic.co/en/integrations/endpoint integration. +- To install Elastic Defend, refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html. + +#### The following steps should be executed to install assets associated with the Lateral Movement Detection integration: +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Lateral Movement Detection and select the integration to see more details about it. +- Under Settings, click Install Lateral Movement Detection assets and follow the prompts to install the assets. + +#### Anomaly Detection Setup +Before you can enable rules for Lateral Movement Detection, you'll need to enable the corresponding Anomaly Detection jobs. +- Before enabling the Anomaly Detection jobs, confirm that the Pivot Transform asset is installed and actively gathering data in the destination index `ml-rdp-lmd`. +- Go to the Kibana homepage. Under Analytics, click Machine Learning. +- Under Anomaly Detection, click Jobs, and then click "Create job". Select the Data View containing your transformed RDP process data i.e.`ml-rdp-lmd`. +- If the selected Data View contains events that match the query in https://github.com/elastic/integrations/blob/main/packages/lmd/kibana/ml_module/lmd-ml.json configuration file, you will see a card for Lateral Movement Detection under "Use preconfigured jobs". +- Keep the default settings and click "Create jobs" to start the anomaly detection jobs and datafeeds. + +---------------------------------- + *Framework*: MITRE ATT&CK^TM^ * Tactic: diff --git a/docs/detections/prebuilt-rules/rule-details/spike-in-remote-file-transfers.asciidoc b/docs/detections/prebuilt-rules/rule-details/spike-in-remote-file-transfers.asciidoc index 7403064b00..635210bfab 100644 --- a/docs/detections/prebuilt-rules/rule-details/spike-in-remote-file-transfers.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/spike-in-remote-file-transfers.asciidoc @@ -40,6 +40,36 @@ A machine learning job has detected an abnormal volume of remote files shared on *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- +The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration. + +### Lateral Movement Detection Setup +The Lateral Movement Detection integration detects lateral movement activity by identifying abnormalities in file and Windows RDP events. Anomalies are detected using Elastic's Anomaly Detection feature. + +#### Prerequisite Requirements: +- Fleet is required for Lateral Movement Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html. +- File events collected by the https://docs.elastic.co/en/integrations/endpoint integration. +- To install Elastic Defend, refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html. + +#### The following steps should be executed to install assets associated with the Lateral Movement Detection integration: +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Lateral Movement Detection and select the integration to see more details about it. +- Under Settings, click Install Lateral Movement Detection assets and follow the prompts to install the assets. + +#### Anomaly Detection Setup +Before you can enable rules for Lateral Movement Detection, you'll need to enable the corresponding Anomaly Detection jobs. +- Go to the Kibana homepage. Under Analytics, click Machine Learning. +- Under Anomaly Detection, click Jobs, and then click "Create job". Select the Data View containing your file events. For example, this would be `logs-endpoint.events.*` if you used Elastic Defend to collect events. +- If the selected Data View contains events that match the query in https://github.com/elastic/integrations/blob/main/packages/lmd/kibana/ml_module/lmd-ml.json configuration file, you will see a card for Lateral Movement Detection under "Use preconfigured jobs". +- Keep the default settings and click "Create jobs" to start the anomaly detection jobs and datafeeds. + +---------------------------------- + *Framework*: MITRE ATT&CK^TM^ * Tactic: diff --git a/docs/detections/prebuilt-rules/rule-details/startup-folder-persistence-via-unsigned-process.asciidoc b/docs/detections/prebuilt-rules/rule-details/startup-folder-persistence-via-unsigned-process.asciidoc index b1ebe743fc..a39cef72bc 100644 --- a/docs/detections/prebuilt-rules/rule-details/startup-folder-persistence-via-unsigned-process.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/startup-folder-persistence-via-unsigned-process.asciidoc @@ -54,7 +54,7 @@ The Windows Startup folder is a special folder in Windows. Programs added to thi This rule looks for unsigned processes writing to the Startup folder locations. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps diff --git a/docs/detections/prebuilt-rules/rule-details/startup-logon-script-added-to-group-policy-object.asciidoc b/docs/detections/prebuilt-rules/rule-details/startup-logon-script-added-to-group-policy-object.asciidoc index 4d570a324c..ab47985254 100644 --- a/docs/detections/prebuilt-rules/rule-details/startup-logon-script-added-to-group-policy-object.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/startup-logon-script-added-to-group-policy-object.asciidoc @@ -85,6 +85,42 @@ Group Policy Objects (GPOs) can be used by attackers to instruct arbitrarily lar - 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 + + +[source, markdown] +---------------------------------- + +The 'Audit Detailed File Share' audit policy must be configured (Success Failure). +Steps to implement the logging policy with with Advanced Audit Configuration: + +``` +Computer Configuration > +Policies > +Windows Settings > +Security Settings > +Advanced Audit Policies Configuration > +Audit Policies > +Object Access > +Audit Detailed File Share (Success,Failure) +``` + +The 'Audit Directory Service Changes' audit policy must be configured (Success Failure). +Steps to implement the logging policy with 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) +``` + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/startup-or-run-key-registry-modification.asciidoc b/docs/detections/prebuilt-rules/rule-details/startup-or-run-key-registry-modification.asciidoc index 1cc989593e..f88b185c3a 100644 --- a/docs/detections/prebuilt-rules/rule-details/startup-or-run-key-registry-modification.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/startup-or-run-key-registry-modification.asciidoc @@ -52,7 +52,7 @@ Identifies run key or startup key registry modifications. In order to survive re Adversaries may achieve persistence by referencing a program with a registry run key. Adding an entry to the run keys in the registry will cause the program referenced to be executed when a user logs in. These programs will executed under the context of the user and will have the account's permissions. This rule looks for this behavior by monitoring a range of registry run keys. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps diff --git a/docs/detections/prebuilt-rules/rule-details/startup-persistence-by-a-suspicious-process.asciidoc b/docs/detections/prebuilt-rules/rule-details/startup-persistence-by-a-suspicious-process.asciidoc index ee7ac26219..f484a08284 100644 --- a/docs/detections/prebuilt-rules/rule-details/startup-persistence-by-a-suspicious-process.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/startup-persistence-by-a-suspicious-process.asciidoc @@ -59,7 +59,7 @@ The Windows Startup folder is a special folder in Windows. Programs added to thi This rule monitors for commonly abused processes writing to the Startup folder locations. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps @@ -107,6 +107,20 @@ This rule monitors for commonly abused processes writing to the Startup folder l - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/statistical-model-detected-c2-beaconing-activity-with-high-confidence.asciidoc b/docs/detections/prebuilt-rules/rule-details/statistical-model-detected-c2-beaconing-activity-with-high-confidence.asciidoc index 0d3bd04380..8cf5ba9ffb 100644 --- a/docs/detections/prebuilt-rules/rule-details/statistical-model-detected-c2-beaconing-activity-with-high-confidence.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/statistical-model-detected-c2-beaconing-activity-with-high-confidence.asciidoc @@ -40,6 +40,30 @@ A statistical model has identified command-and-control (C2) beaconing activity w *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- +The rule requires the Network Beaconing Identification integration assets to be installed, as well as network logs collected by the Elastic Defend or Network Packet Capture integrations. + +### Network Beaconing Identification Setup +The Network Beaconing Identification integration consists of a statistical framework to identify C2 beaconing activity in network logs. + +#### Prerequisite Requirements: +- Fleet is required for Network Beaconing Identification. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html. +- Network events collected by the https://docs.elastic.co/en/integrations/endpoint or https://docs.elastic.co/integrations/network_traffic integration. +- To install Elastic Defend, refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html. +- To add the Network Packet Capture integration to an Elastic Agent policy, refer to https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html guide. + +#### The following steps should be executed to install assets associated with the Network Beaconing Identification integration: +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Network Beaconing Identification and select the integration to see more details about it. +- Under Settings, click "Install Network Beaconing Identification assets" and follow the prompts to install the assets. + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/statistical-model-detected-c2-beaconing-activity.asciidoc b/docs/detections/prebuilt-rules/rule-details/statistical-model-detected-c2-beaconing-activity.asciidoc index 4e8f1c4e69..7c18ee05f6 100644 --- a/docs/detections/prebuilt-rules/rule-details/statistical-model-detected-c2-beaconing-activity.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/statistical-model-detected-c2-beaconing-activity.asciidoc @@ -40,6 +40,30 @@ A statistical model has identified command-and-control (C2) beaconing activity. *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- +The rule requires the Network Beaconing Identification integration assets to be installed, as well as network logs collected by the Elastic Defend or Network Packet Capture integrations. + +### Network Beaconing Identification Setup +The Network Beaconing Identification integration consists of a statistical framework to identify C2 beaconing activity in network logs. + +#### Prerequisite Requirements: +- Fleet is required for Network Beaconing Identification. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html. +- Network events collected by the https://docs.elastic.co/en/integrations/endpoint or https://docs.elastic.co/integrations/network_traffic integration. +- To install Elastic Defend, refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html. +- To add the Network Packet Capture integration to an Elastic Agent policy, refer to https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html guide. + +#### The following steps should be executed to install assets associated with the Network Beaconing Identification integration: +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Network Beaconing Identification and select the integration to see more details about it. +- Under Settings, click "Install Network Beaconing Identification assets" and follow the prompts to install the assets. + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/stolen-credentials-used-to-login-to-okta-account-after-mfa-reset.asciidoc b/docs/detections/prebuilt-rules/rule-details/stolen-credentials-used-to-login-to-okta-account-after-mfa-reset.asciidoc index 912c9ce620..df096e8c7f 100644 --- a/docs/detections/prebuilt-rules/rule-details/stolen-credentials-used-to-login-to-okta-account-after-mfa-reset.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/stolen-credentials-used-to-login-to-okta-account-after-mfa-reset.asciidoc @@ -83,6 +83,14 @@ Typically, adversaries initially extract credentials from targeted endpoints thr ## Setup ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Okta and Elastic Defend fleet integration structured data is required to be compatible with this rule. Directory services integration in Okta with AD synced is also required for this rule to be effective as it relies on triaging `user.name` from Okta and Elastic Defend events. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/sublime-plugin-or-application-script-modification.asciidoc b/docs/detections/prebuilt-rules/rule-details/sublime-plugin-or-application-script-modification.asciidoc index 972f258539..8885489044 100644 --- a/docs/detections/prebuilt-rules/rule-details/sublime-plugin-or-application-script-modification.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/sublime-plugin-or-application-script-modification.asciidoc @@ -40,6 +40,38 @@ Adversaries may create or modify the Sublime application plugins or scripts to e *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### The following steps should be executed in order to add the Elastic Defend integration on a macOS 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, for MacOS it is recommended to select "Traditional Endpoints". +- 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/sudo-command-enumeration-detected.asciidoc b/docs/detections/prebuilt-rules/rule-details/sudo-command-enumeration-detected.asciidoc index 877e3bd91f..90599adf0a 100644 --- a/docs/detections/prebuilt-rules/rule-details/sudo-command-enumeration-detected.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/sudo-command-enumeration-detected.asciidoc @@ -38,6 +38,38 @@ This rule monitors for the usage of the sudo -l command, which is used to list t *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/suid-sguid-enumeration-detected.asciidoc b/docs/detections/prebuilt-rules/rule-details/suid-sguid-enumeration-detected.asciidoc index 910b647d52..8eb08a5c85 100644 --- a/docs/detections/prebuilt-rules/rule-details/suid-sguid-enumeration-detected.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suid-sguid-enumeration-detected.asciidoc @@ -39,6 +39,38 @@ This rule monitors for the usage of the "find" command in conjunction with SUID *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/sunburst-command-and-control-activity.asciidoc b/docs/detections/prebuilt-rules/rule-details/sunburst-command-and-control-activity.asciidoc index 0584e66168..3ef1878b20 100644 --- a/docs/detections/prebuilt-rules/rule-details/sunburst-command-and-control-activity.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/sunburst-command-and-control-activity.asciidoc @@ -52,12 +52,12 @@ The malware known as SUNBURST targets the SolarWind's Orion business software fo SUNBURST is a trojanized version of a digitally signed SolarWinds Orion plugin called SolarWinds.Orion.Core.BusinessLayer.dll. The plugin contains a backdoor that communicates via HTTP to third-party servers. After an initial dormant period of up to two weeks, SUNBURST may retrieve and execute commands that instruct the backdoor to transfer files, execute files, profile the system, reboot the system, and disable system services. The malware's network traffic attempts to blend in with legitimate SolarWinds activity by imitating the Orion Improvement Program (OIP) protocol, and the malware stores persistent state data within legitimate plugin configuration files. The backdoor uses multiple obfuscated blocklists to identify processes, services, and drivers associated with forensic and anti-virus tools. -More details on SUNBURST can be found on the [Mandiant Report](https://www.mandiant.com/resources/sunburst-additional-technical-details). +More details on SUNBURST can be found on the https://www.mandiant.com/resources/sunburst-additional-technical-details. This rule identifies suspicious network connections that attempt to blend in with legitimate SolarWinds activity by imitating the Orion Improvement Program (OIP) protocol behavior. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-activity-reported-by-okta-user.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-activity-reported-by-okta-user.asciidoc index 1c94d5f5a7..a00dde2ba3 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-activity-reported-by-okta-user.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-activity-reported-by-okta-user.asciidoc @@ -49,6 +49,14 @@ Detects when a user reports suspicious activity for their Okta account. These ev ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-antimalware-scan-interface-dll.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-antimalware-scan-interface-dll.asciidoc index eb2d3daf2d..b910318072 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-antimalware-scan-interface-dll.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-antimalware-scan-interface-dll.asciidoc @@ -36,7 +36,7 @@ Identifies the creation of the Antimalware Scan Interface (AMSI) DLL in an unusu * Resources: Investigation Guide * Data Source: Elastic Defend -*Version*: 7 +*Version*: 6 *Rule authors*: @@ -59,7 +59,7 @@ The Windows Antimalware Scan Interface (AMSI) is a versatile interface standard Attackers might copy a rogue AMSI DLL to an unusual location to prevent the process from loading the legitimate module, achieving a bypass to execute malicious code. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps @@ -105,7 +105,7 @@ Attackers might copy a rogue AMSI DLL to an unusual location to prevent the proc [source, js] ---------------------------------- -file where host.os.type == "windows" and event.type != "deletion" and file.path != null and +file where host.os.type == "windows" and event.action != "deletion" and file.path != null and file.name : ("amsi.dll", "amsi") and not file.path : ("?:\\Windows\\system32\\amsi.dll", "?:\\Windows\\Syswow64\\amsi.dll", "?:\\$WINDOWS.~BT\\NewOS\\Windows\\WinSXS\\*", "?:\\$WINDOWS.~BT\\NewOS\\Windows\\servicing\\LCU\\*", "?:\\$WINDOWS.~BT\\Work\\*\\*", "?:\\Windows\\SoftwareDistribution\\Download\\*") ---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-apt-package-manager-execution.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-apt-package-manager-execution.asciidoc index 9da5041935..9673318bfc 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-apt-package-manager-execution.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-apt-package-manager-execution.asciidoc @@ -40,6 +40,38 @@ Detects suspicious process events executed by the APT package manager, potential *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-apt-package-manager-network-connection.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-apt-package-manager-network-connection.asciidoc index 7bd95485db..f06747894c 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-apt-package-manager-network-connection.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-apt-package-manager-network-connection.asciidoc @@ -40,6 +40,38 @@ Detects suspicious network events executed by the APT package manager, potential *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-automator-workflows-execution.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-automator-workflows-execution.asciidoc index eccefc2cc6..7e23b0cf2c 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-automator-workflows-execution.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-automator-workflows-execution.asciidoc @@ -40,6 +40,38 @@ Identifies the execution of the Automator Workflows process followed by a networ *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### The following steps should be executed in order to add the Elastic Defend integration on a macOS 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, for MacOS it is recommended to select "Traditional Endpoints". +- 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-browser-child-process.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-browser-child-process.asciidoc index e3a5ba608e..cec0f8faed 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-browser-child-process.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-browser-child-process.asciidoc @@ -42,6 +42,38 @@ Identifies the execution of a suspicious browser child process. Adversaries may *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### The following steps should be executed in order to add the Elastic Defend integration on a macOS 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, for MacOS it is recommended to select "Traditional Endpoints". +- 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-calendar-file-modification.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-calendar-file-modification.asciidoc index d72f20f851..0b7b014de9 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-calendar-file-modification.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-calendar-file-modification.asciidoc @@ -42,6 +42,38 @@ Identifies suspicious modifications of the calendar file by an unusual process. *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### The following steps should be executed in order to add the Elastic Defend integration on a macOS 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, for MacOS it is recommended to select "Traditional Endpoints". +- 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-certutil-commands.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-certutil-commands.asciidoc index 7b22278e45..6dd98e3a8c 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-certutil-commands.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-certutil-commands.asciidoc @@ -64,7 +64,7 @@ Identifies suspicious commands being used with certutil.exe. CertUtil is a nativ Attackers can abuse `certutil.exe` utility to download and/or deobfuscate malware, offensive security tools, and certificates from external sources to take the next steps in a compromised environment. This rule identifies command line arguments used to accomplish these behaviors. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-child-process-of-adobe-acrobat-reader-update-service.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-child-process-of-adobe-acrobat-reader-update-service.asciidoc index a56d913eef..b4422c0d7e 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-child-process-of-adobe-acrobat-reader-update-service.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-child-process-of-adobe-acrobat-reader-update-service.asciidoc @@ -41,6 +41,38 @@ Detects attempts to exploit privilege escalation vulnerabilities related to the *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### The following steps should be executed in order to add the Elastic Defend integration on a macOS 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, for MacOS it is recommended to select "Traditional Endpoints". +- 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-cmd-execution-via-wmi.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-cmd-execution-via-wmi.asciidoc index 95ae1e2b60..014f738869 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-cmd-execution-via-wmi.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-cmd-execution-via-wmi.asciidoc @@ -43,6 +43,20 @@ Identifies suspicious command execution (cmd) via Windows Management Instrumenta *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-content-extracted-or-decompressed-via-funzip.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-content-extracted-or-decompressed-via-funzip.asciidoc index 56f202b268..d1906d5703 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-content-extracted-or-decompressed-via-funzip.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-content-extracted-or-decompressed-via-funzip.asciidoc @@ -42,6 +42,38 @@ Identifies when suspicious content is extracted from a file and subsequently dec *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-crontab-creation-or-modification.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-crontab-creation-or-modification.asciidoc index b48c3e056a..987ccee2a4 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-crontab-creation-or-modification.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-crontab-creation-or-modification.asciidoc @@ -41,6 +41,38 @@ Identifies attempts to create or modify a crontab via a process that is not cron *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### The following steps should be executed in order to add the Elastic Defend integration on a macOS 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, for MacOS it is recommended to select "Traditional Endpoints". +- 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-data-encryption-via-openssl-utility.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-data-encryption-via-openssl-utility.asciidoc index 506adfa79a..925c4f4851 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-data-encryption-via-openssl-utility.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-data-encryption-via-openssl-utility.asciidoc @@ -41,6 +41,38 @@ Identifies when the openssl command-line utility is used to encrypt multiple fil *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-dll-loaded-for-persistence-or-privilege-escalation.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-dll-loaded-for-persistence-or-privilege-escalation.asciidoc index 8838e15e5e..89e9fcc723 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-dll-loaded-for-persistence-or-privilege-escalation.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-dll-loaded-for-persistence-or-privilege-escalation.asciidoc @@ -98,6 +98,20 @@ Attackers can execute malicious code by abusing missing modules that processes t - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-dynamic-linker-discovery-via-od.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-dynamic-linker-discovery-via-od.asciidoc index ba81288948..061c2cdd6d 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-dynamic-linker-discovery-via-od.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-dynamic-linker-discovery-via-od.asciidoc @@ -42,6 +42,38 @@ Monitors for dynamic linker discovery via the od utility. od (octal dump) is a c *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-emond-child-process.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-emond-child-process.asciidoc index d3548d5a56..103fa29cbd 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-emond-child-process.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-emond-child-process.asciidoc @@ -40,6 +40,38 @@ Identifies the execution of a suspicious child process of the Event Monitor Daem *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### The following steps should be executed in order to add the Elastic Defend integration on a macOS 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, for MacOS it is recommended to select "Traditional Endpoints". +- 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-endpoint-security-parent-process.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-endpoint-security-parent-process.asciidoc index 0bcbbe93d1..135aa94a84 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-endpoint-security-parent-process.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-endpoint-security-parent-process.asciidoc @@ -42,6 +42,20 @@ A suspicious Endpoint Security parent process was detected. This may indicate a *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-execution-from-a-mounted-device.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-execution-from-a-mounted-device.asciidoc index b4335045c1..3a87ecae68 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-execution-from-a-mounted-device.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-execution-from-a-mounted-device.asciidoc @@ -44,6 +44,20 @@ Identifies when a script interpreter or signed binary is launched via a non-stan *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-execution-via-scheduled-task.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-execution-via-scheduled-task.asciidoc index 627a6e72be..b421230c9b 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-execution-via-scheduled-task.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-execution-via-scheduled-task.asciidoc @@ -41,6 +41,20 @@ Identifies execution of a suspicious program via scheduled tasks by looking at p *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-explorer-child-process.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-explorer-child-process.asciidoc index dba3babf23..82b3af49f2 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-explorer-child-process.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-explorer-child-process.asciidoc @@ -44,6 +44,20 @@ Identifies a suspicious Windows explorer child process. Explorer.exe can be abus *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-file-changes-activity-detected.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-file-changes-activity-detected.asciidoc index d595423c9f..155c894152 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-file-changes-activity-detected.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-file-changes-activity-detected.asciidoc @@ -38,6 +38,38 @@ This rule identifies a sequence of 100 file extension rename events within a set *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-file-creation-in-etc-for-persistence.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-file-creation-in-etc-for-persistence.asciidoc index fcfe8c1e6c..d3c7f436ae 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-file-creation-in-etc-for-persistence.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-file-creation-in-etc-for-persistence.asciidoc @@ -61,8 +61,8 @@ By creating or modifying specific system-wide configuration files, attackers can This rule monitors for the creation of the most common system-wide configuration files and scripts abused by attackers for persistence. > **Note**: -> This investigation guide uses the {security-guide}/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. -> This investigation guide uses {security-guide}/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. #### Possible Investigation Steps @@ -122,6 +122,38 @@ This rule monitors for the creation of the most common system-wide configuration - Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. - Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). +---------------------------------- + +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-file-creation-via-kworker.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-file-creation-via-kworker.asciidoc index 23a5350474..92e5068bda 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-file-creation-via-kworker.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-file-creation-via-kworker.asciidoc @@ -55,8 +55,8 @@ Attackers may attempt to evade detection by masquerading as a kernel worker proc This rule monitors for suspicious file creation events through the kworker process. This is not common, and could indicate malicious behaviour. > **Note**: -> This investigation guide uses the {security-guide}/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. -> This investigation guide uses {security-guide}/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. #### Possible Investigation Steps @@ -111,6 +111,40 @@ This rule monitors for suspicious file creation events through the kworker proce - Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. - Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). +---------------------------------- + +==== Setup + + +[source, markdown] +---------------------------------- +## 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. + +#### 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. +- We suggest to select "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. +- 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. + + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-hidden-child-process-of-launchd.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-hidden-child-process-of-launchd.asciidoc index 1bafabc4c4..044bbac748 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-hidden-child-process-of-launchd.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-hidden-child-process-of-launchd.asciidoc @@ -43,6 +43,38 @@ Identifies the execution of a launchd child process with a hidden file. An adver *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### The following steps should be executed in order to add the Elastic Defend integration on a macOS 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, for MacOS it is recommended to select "Traditional Endpoints". +- 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-html-file-creation.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-html-file-creation.asciidoc index 78ffc7aab8..cdc0bbded0 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-html-file-creation.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-html-file-creation.asciidoc @@ -38,6 +38,20 @@ Identifies the execution of a browser process to open an HTML file with high ent *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-image-load-taskschd-dll-from-ms-office.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-image-load-taskschd-dll-from-ms-office.asciidoc index 9d87652824..15cd5a02ca 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-image-load-taskschd-dll-from-ms-office.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-image-load-taskschd-dll-from-ms-office.asciidoc @@ -62,7 +62,7 @@ Microsoft Office, a widely used suite of productivity applications, is frequentl This rule looks for an MS Office process loading `taskschd.dll`, which may indicate an adversary abusing COM to configure a scheduled task. This can happen as part of a phishing attack, when a malicious office document registers the scheduled task to download the malware "stage 2" or to establish persistent access. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. ### Possible investigation steps @@ -118,6 +118,20 @@ This rule looks for an MS Office process loading `taskschd.dll`, which may indic ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-java-child-process.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-java-child-process.asciidoc index 1dc90d4f7f..bc90759337 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-java-child-process.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-java-child-process.asciidoc @@ -83,6 +83,21 @@ This rule identifies a suspicious child process of the Java interpreter process. - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-kworker-uid-elevation.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-kworker-uid-elevation.asciidoc index 0d2d2f3271..d4433c78b4 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-kworker-uid-elevation.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-kworker-uid-elevation.asciidoc @@ -39,6 +39,39 @@ Monitors for the elevation of regular user permissions to root permissions throu *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- We suggest to select "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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-lsass-access-via-malseclogon.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-lsass-access-via-malseclogon.asciidoc index e9389a938e..d1fa11e17e 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-lsass-access-via-malseclogon.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-lsass-access-via-malseclogon.asciidoc @@ -41,6 +41,20 @@ Identifies suspicious access to LSASS handle from a call trace pointing to seclo *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-lsass-process-access.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-lsass-process-access.asciidoc index 54a4868935..3e2f95ba36 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-lsass-process-access.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-lsass-process-access.asciidoc @@ -41,6 +41,19 @@ Identifies access attempts to LSASS handle, this may indicate an attempt to dump *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-macos-ms-office-child-process.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-macos-ms-office-child-process.asciidoc index e603574594..a5d888739b 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-macos-ms-office-child-process.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-macos-ms-office-child-process.asciidoc @@ -40,6 +40,38 @@ Identifies suspicious child processes of frequently targeted Microsoft Office ap *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### The following steps should be executed in order to add the Elastic Defend integration on a macOS 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, for MacOS it is recommended to select "Traditional Endpoints". +- 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-microsoft-365-mail-access-by-clientappid.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-microsoft-365-mail-access-by-clientappid.asciidoc index e851c0b6ff..59fb9ee7db 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-microsoft-365-mail-access-by-clientappid.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-microsoft-365-mail-access-by-clientappid.asciidoc @@ -48,6 +48,14 @@ Identifies when a Microsoft 365 Mailbox is accessed by a ClientAppId that was ob ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-microsoft-diagnostics-wizard-execution.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-microsoft-diagnostics-wizard-execution.asciidoc index 70aa6d1f68..2012d237da 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-microsoft-diagnostics-wizard-execution.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-microsoft-diagnostics-wizard-execution.asciidoc @@ -45,6 +45,20 @@ Identifies potential abuse of the Microsoft Diagnostics Troubleshooting Wizard ( *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-mining-process-creation-event.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-mining-process-creation-event.asciidoc index adcdf37539..35d2355fec 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-mining-process-creation-event.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-mining-process-creation-event.asciidoc @@ -40,6 +40,38 @@ Identifies service creation events of common mining services, possibly indicatin *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-modprobe-file-event.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-modprobe-file-event.asciidoc index 8f14e269cb..e8220b50ad 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-modprobe-file-event.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-modprobe-file-event.asciidoc @@ -38,6 +38,34 @@ Detects file events involving kernel modules in modprobe configuration files, wh *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +This rule requires the use of the `auditd_manager` integration. `Auditd_manager` is a tool designed to simplify and enhance the management of the audit subsystem in Linux systems. It provides a user-friendly interface and automation capabilities for configuring and monitoring system auditing through the auditd daemon. With `auditd_manager`, administrators can easily define audit rules, track system events, and generate comprehensive audit reports, improving overall security and compliance in the system. The following steps should be executed in order to install and deploy `auditd_manager` on a Linux system. + +``` +Kibana --> +Management --> +Integrations --> +Auditd Manager --> +Add Auditd Manager +``` + +`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 to trigger, the following additional audit rules are required to be added to the integration: +``` +-w /etc/modprobe.conf -p wa -k modprobe +-w /etc/modprobe.d -p wa -k modprobe +``` + +Add the newly installed `auditd manager` to an agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-module-loaded-by-lsass.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-module-loaded-by-lsass.asciidoc index eba47d9a62..b38df3c007 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-module-loaded-by-lsass.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-module-loaded-by-lsass.asciidoc @@ -41,6 +41,20 @@ Identifies LSASS loading an unsigned or untrusted DLL. Windows Security Support *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-ms-office-child-process.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-ms-office-child-process.asciidoc index 52bee19697..0846cb7443 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-ms-office-child-process.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-ms-office-child-process.asciidoc @@ -101,6 +101,20 @@ This rule looks for suspicious processes spawned by MS Office programs. This is - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-ms-outlook-child-process.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-ms-outlook-child-process.asciidoc index 7f2c5a8117..ff2efdc7b9 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-ms-outlook-child-process.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-ms-outlook-child-process.asciidoc @@ -99,6 +99,20 @@ This rule looks for suspicious processes spawned by MS Outlook, which can be the - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-net-code-compilation.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-net-code-compilation.asciidoc index 7255454538..d7c766329b 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-net-code-compilation.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-net-code-compilation.asciidoc @@ -43,6 +43,20 @@ Identifies executions of .NET compilers with suspicious parent processes, which *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-net-reflection-via-powershell.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-net-reflection-via-powershell.asciidoc index 5359e35bbe..d374bb241f 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-net-reflection-via-powershell.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-net-reflection-via-powershell.asciidoc @@ -57,7 +57,7 @@ PowerShell is one of the main tools system administrators use for automation, re Attackers can use .NET reflection to load PEs and DLLs in memory. These payloads are commonly embedded in the script, which can circumvent file-based security protections. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps @@ -108,6 +108,30 @@ Attackers can use .NET reflection to load PEs and DLLs in memory. These payloads - 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 + + +[source, markdown] +---------------------------------- + +The 'PowerShell Script Block Logging' logging policy must be enabled. +Steps to implement the logging policy with with Advanced Audit Configuration: + +``` +Computer Configuration > +Administrative Templates > +Windows PowerShell > +Turn on PowerShell Script Block Logging (Enable) +``` + +Steps to implement the logging policy via registry: + +``` +reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1 +``` + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-network-activity-to-the-internet-by-previously-unknown-executable.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-network-activity-to-the-internet-by-previously-unknown-executable.asciidoc index 4a32c11d54..09f46c8192 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-network-activity-to-the-internet-by-previously-unknown-executable.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-network-activity-to-the-internet-by-previously-unknown-executable.asciidoc @@ -57,8 +57,8 @@ After being installed, malware will often call out to its command and control se This rule leverages the new terms rule type to detect previously unknown processes, initiating network connections to external IP-addresses. > **Note**: -> This investigation guide uses the {security-guide}/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. -> This investigation guide uses {security-guide}/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. #### Possible investigation steps @@ -106,6 +106,75 @@ This rule leverages the new terms rule type to detect previously unknown process - Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector. - Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). +---------------------------------- + +==== Setup + + +[source, markdown] +---------------------------------- + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Auditbeat +- Filebeat +- Packetbeat + + +### 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. + +#### 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. +- We suggest to select "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. +- 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. + +### Auditbeat Setup +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + +#### The following steps should be executed in order to add the Auditbeat on a Linux System: +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html. + +### Filebeat Setup +Filebeat is a lightweight shipper for forwarding and centralizing log data. Installed as an agent on your servers, Filebeat monitors the log files or locations that you specify, collects log events, and forwards them either to Elasticsearch or Logstash for indexing. + +#### The following steps should be executed in order to add the Filebeat on a Linux System: +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/filebeat/current/setup-repositories.html. +- To run Filebeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/running-on-docker.html. +- To run Filebeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/running-on-kubernetes.html. +- For quick start information for Filebeat refer to the https://www.elastic.co/guide/en/beats/filebeat/8.11/filebeat-installation-configuration.html. +- For complete “Setup and Run Filebeat” information refer to the https://www.elastic.co/guide/en/beats/filebeat/current/setting-up-and-running.html. + +### Packetbeat Setup +Packetbeat is a real-time network packet analyzer that you can use for application monitoring, performance analytics, and threat detection. Packetbeat works by capturing the network traffic between your application servers, decoding the application layer protocols (HTTP, MySQL, Redis, and so on), correlating the requests with the responses, and recording the interesting fields for each transaction. + +#### The following steps should be executed in order to add the Packetbeat on a Linux System: +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/packetbeat/current/setup-repositories.html. +- To run Packetbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/packetbeat/current/running-on-docker.html. +- For quick start information for Packetbeat refer to the https://www.elastic.co/guide/en/beats/packetbeat/current/packetbeat-installation-configuration.html. +- For complete “Setup and Run Packetbeat” information refer to the https://www.elastic.co/guide/en/beats/packetbeat/current/setting-up-and-running.html. + + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-network-connection-via-sudo-binary.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-network-connection-via-sudo-binary.asciidoc index 373c52d5ed..7ee0535d62 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-network-connection-via-sudo-binary.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-network-connection-via-sudo-binary.asciidoc @@ -38,6 +38,38 @@ Detects network connections initiated by the "sudo" binary. This behavior is unc *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-network-connection-via-systemd.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-network-connection-via-systemd.asciidoc index f0a4d23f42..daff33912a 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-network-connection-via-systemd.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-network-connection-via-systemd.asciidoc @@ -40,6 +40,38 @@ Detects suspicious network events executed by systemd, potentially indicating pe *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-passwd-file-event-action.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-passwd-file-event-action.asciidoc index a4a2ee4adf..8395bd7ab4 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-passwd-file-event-action.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-passwd-file-event-action.asciidoc @@ -39,6 +39,59 @@ Monitors for the generation of a passwd password entry via openssl, followed by *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +This rule requires data coming in from Elastic Defend and Auditd Manager. + +### 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. + +#### 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. +- We suggest to select "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. +- 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. + +### 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" on a Linux 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. + +#### 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 the following additional audit rules are required to be added to the integration: + -- "-w /etc/passwd -p wa -k etcpasswd" + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-pdf-reader-child-process.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-pdf-reader-child-process.asciidoc index 9aa474ef57..bb22767558 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-pdf-reader-child-process.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-pdf-reader-child-process.asciidoc @@ -98,6 +98,20 @@ This rule looks for commonly abused built-in utilities spawned by a PDF reader p - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-portable-executable-encoded-in-powershell-script.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-portable-executable-encoded-in-powershell-script.asciidoc index bd4fb4efe0..e5ada19566 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-portable-executable-encoded-in-powershell-script.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-portable-executable-encoded-in-powershell-script.asciidoc @@ -57,7 +57,7 @@ PowerShell is one of the main tools system administrators use for automation, re Attackers can abuse PowerShell in-memory capabilities to inject executables into memory without touching the disk, bypassing file-based security protections. These executables are generally base64 encoded. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps @@ -107,6 +107,30 @@ Attackers can abuse PowerShell in-memory capabilities to inject executables into - 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 + + +[source, markdown] +---------------------------------- + +The 'PowerShell Script Block Logging' logging policy must be enabled. +Steps to implement the logging policy with with Advanced Audit Configuration: + +``` +Computer Configuration > +Administrative Templates > +Windows PowerShell > +Turn on PowerShell Script Block Logging (Enable) +``` + +Steps to implement the logging policy via registry: + +``` +reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1 +``` + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-print-spooler-file-deletion.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-print-spooler-file-deletion.asciidoc index c1d45552de..025a1b4010 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-print-spooler-file-deletion.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-print-spooler-file-deletion.asciidoc @@ -45,6 +45,20 @@ Detects deletion of print driver files by an unusual process. This may indicate *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-print-spooler-spl-file-created.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-print-spooler-spl-file-created.asciidoc index c88bc57c78..17cd807ec1 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-print-spooler-spl-file-created.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-print-spooler-spl-file-created.asciidoc @@ -60,7 +60,7 @@ Print Spooler is a Windows service enabled by default in all Windows clients and The Print Spooler service has some known vulnerabilities that attackers can abuse to escalate privileges to SYSTEM, like CVE-2020-1048 and CVE-2020-1337. This rule looks for unusual processes writing SPL files to the location `?:\Windows\System32\spool\PRINTERS\`, which is an essential step in exploiting these vulnerabilities. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps @@ -105,6 +105,20 @@ The Print Spooler service has some known vulnerabilities that attackers can abus - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-printspooler-service-executable-file-creation.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-printspooler-service-executable-file-creation.asciidoc index cd4e7a22c7..c239aee89b 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-printspooler-service-executable-file-creation.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-printspooler-service-executable-file-creation.asciidoc @@ -46,6 +46,20 @@ Detects attempts to exploit privilege escalation vulnerabilities related to the *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-proc-maps-discovery.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-proc-maps-discovery.asciidoc index b7270facf0..9f6d2e93db 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-proc-maps-discovery.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-proc-maps-discovery.asciidoc @@ -40,6 +40,38 @@ Monitors for /proc/*/maps file reads. The /proc/*/maps file in Linux provides a *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-proc-pseudo-file-system-enumeration.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-proc-pseudo-file-system-enumeration.asciidoc index 524c901bf6..387d74a2df 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-proc-pseudo-file-system-enumeration.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-proc-pseudo-file-system-enumeration.asciidoc @@ -38,6 +38,33 @@ This rule monitors for a rapid enumeration of 25 different proc cmd, stat, and e *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +This rule requires the use of the `auditd_manager` integration. `Auditd_manager` is a tool designed to simplify and enhance the management of the audit subsystem in Linux systems. It provides a user-friendly interface and automation capabilities for configuring and monitoring system auditing through the auditd daemon. With `auditd_manager`, administrators can easily define audit rules, track system events, and generate comprehensive audit reports, improving overall security and compliance in the system. The following steps should be executed in order to install and deploy `auditd_manager` on a Linux system. + +``` +Kibana --> +Management --> +Integrations --> +Auditd Manager --> +Add Auditd Manager +``` + +`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 to trigger, the following additional audit rules are required to be added to the integration: +``` +-w /proc/ -p r -k audit_proc +``` + +Add the newly installed `auditd manager` to an agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-process-access-via-direct-system-call.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-process-access-via-direct-system-call.asciidoc index 44560125be..fa81ee7993 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-process-access-via-direct-system-call.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-process-access-via-direct-system-call.asciidoc @@ -55,12 +55,12 @@ Identifies suspicious process access events from an unknown memory region. Endpo Endpoint security solutions usually hook userland Windows APIs in order to decide if the code that is being executed is malicious or not. It's possible to bypass hooked functions by writing malicious functions that call syscalls directly. -More context and technical details can be found in this [research blog](https://outflank.nl/blog/2019/06/19/red-team-tactics-combining-direct-system-calls-and-srdi-to-bypass-av-edr/). +More context and technical details can be found in this https://outflank.nl/blog/2019/06/19/red-team-tactics-combining-direct-system-calls-and-srdi-to-bypass-av-edr/. This rule identifies suspicious process access events from an unknown memory region. Attackers can use direct system calls to bypass security solutions that rely on hooks. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps @@ -104,6 +104,20 @@ This rule identifies suspicious process access events from an unknown memory reg - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-process-execution-via-renamed-psexec-executable.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-process-execution-via-renamed-psexec-executable.asciidoc index 505f1efcb1..9ce571d201 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-process-execution-via-renamed-psexec-executable.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-process-execution-via-renamed-psexec-executable.asciidoc @@ -81,6 +81,20 @@ This rule identifies instances where the PsExec service component is executed us - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-process-spawned-from-motd-detected.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-process-spawned-from-motd-detected.asciidoc index d092956595..8cda26c31a 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-process-spawned-from-motd-detected.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-process-spawned-from-motd-detected.asciidoc @@ -59,8 +59,8 @@ Attackers can abuse message-of-the-day (motd) files to run scripts, commands or This rule identifies the execution of potentially malicious processes from a MOTD script, which is not likely to occur as default benign behavior. > **Note**: -> This investigation guide uses the {security-guide}/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. -> This investigation guide uses {security-guide}/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. #### Possible Investigation Steps @@ -107,6 +107,38 @@ This rule identifies the execution of potentially malicious processes from a MOT - Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR). +---------------------------------- + +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-rdp-activex-client-loaded.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-rdp-activex-client-loaded.asciidoc index 7503714dcc..b92a5a3c60 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-rdp-activex-client-loaded.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-rdp-activex-client-loaded.asciidoc @@ -44,6 +44,20 @@ Identifies suspicious Image Loading of the Remote Desktop Services ActiveX Clien *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-remote-registry-access-via-sebackupprivilege.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-remote-registry-access-via-sebackupprivilege.asciidoc index 9f4aa346cb..f07b17563d 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-remote-registry-access-via-sebackupprivilege.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-remote-registry-access-via-sebackupprivilege.asciidoc @@ -83,6 +83,40 @@ This rule identifies remote access to the registry using an account with Backup - 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 + + +[source, markdown] +---------------------------------- + +The 'Audit Detailed File Share' audit policy is required be configured (Success) on Domain Controllers and Sensitive Windows Servers. +Steps to implement the logging policy with with Advanced Audit Configuration: +``` +Computer Configuration > +Policies > +Windows Settings > +Security Settings > +Advanced Audit Policies Configuration > +Audit Policies > +Object Access > +Audit Detailed File Share (Success) +``` + +The 'Special Logon' audit policy must be configured (Success). +Steps to implement the logging policy with with Advanced Audit Configuration: +``` +Computer Configuration > +Policies > +Windows Settings > +Security Settings > +Advanced Audit Policies Configuration > +Audit Policies > +Logon/Logoff > +Special Logon (Success) +``` + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-renaming-of-esxi-files.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-renaming-of-esxi-files.asciidoc index 9624bf3002..104e913d54 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-renaming-of-esxi-files.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-renaming-of-esxi-files.asciidoc @@ -40,6 +40,38 @@ Identifies instances where VMware-related files, such as those with extensions l *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-renaming-of-esxi-index-html-file.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-renaming-of-esxi-index-html-file.asciidoc index 68e3340d6c..8f0186e0fc 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-renaming-of-esxi-index-html-file.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-renaming-of-esxi-index-html-file.asciidoc @@ -40,6 +40,38 @@ Identifies instances where the "index.html" file within the "/usr/lib/vmware/*" *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-service-was-installed-in-the-system.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-service-was-installed-in-the-system.asciidoc index 16522d71cf..4e57e3e691 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-service-was-installed-in-the-system.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-service-was-installed-in-the-system.asciidoc @@ -54,7 +54,7 @@ Attackers may create new services to execute system shells and other command exe This rule looks for suspicious services being created with suspicious traits compatible with the above behavior. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### 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. diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-solarwinds-child-process.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-solarwinds-child-process.asciidoc index 75afc75ca2..43b1efc0d4 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-solarwinds-child-process.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-solarwinds-child-process.asciidoc @@ -45,6 +45,20 @@ A suspicious SolarWinds child process was detected, which may indicate an attemp *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-startup-shell-folder-modification.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-startup-shell-folder-modification.asciidoc index aa0f392c76..e97bb3692b 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-startup-shell-folder-modification.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-startup-shell-folder-modification.asciidoc @@ -54,7 +54,7 @@ Identifies suspicious startup shell folder modifications to change the default S Techniques used within malware and by adversaries often leverage the Windows registry to store malicious programs for persistence. Startup shell folders are often targeted as they are not as prevalent as normal Startup folder paths so this behavior may evade existing AV/EDR solutions. These programs may also run with higher privileges which can be ideal for an attacker. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-symbolic-link-created.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-symbolic-link-created.asciidoc index dadbedcc9a..8a36b2ec80 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-symbolic-link-created.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-symbolic-link-created.asciidoc @@ -41,6 +41,38 @@ Identifies the creation of a symbolic link to a suspicious file or location. A s *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-sysctl-file-event.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-sysctl-file-event.asciidoc index 3476839c41..b9caccdea4 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-sysctl-file-event.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-sysctl-file-event.asciidoc @@ -38,6 +38,35 @@ Monitors file events on sysctl configuration files (e.g., /etc/sysctl.conf, /etc *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +This rule requires the use of the `auditd_manager` integration. `Auditd_manager` is a tool designed to simplify and enhance the management of the audit subsystem in Linux systems. It provides a user-friendly interface and automation capabilities for configuring and monitoring system auditing through the auditd daemon. With `auditd_manager`, administrators can easily define audit rules, track system events, and generate comprehensive audit reports, improving overall security and compliance in the system. The following steps should be executed in order to install and deploy `auditd_manager` on a Linux system. + +``` +Kibana --> +Management --> +Integrations --> +Auditd Manager --> +Add Auditd Manager +``` + +`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 to trigger, the following additional audit rules are required to be added to the integration: + +``` +-w /etc/sysctl.conf -p wa -k sysctl +-w /etc/sysctl.d -p wa -k sysctl +``` + +Add the newly installed `auditd manager` to an agent policy, and deploy the agent on a Linux system from which auditd log files are desirable. + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-system-commands-executed-by-previously-unknown-executable.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-system-commands-executed-by-previously-unknown-executable.asciidoc index 5f14e26088..ffe2617311 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-system-commands-executed-by-previously-unknown-executable.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-system-commands-executed-by-previously-unknown-executable.asciidoc @@ -40,6 +40,38 @@ This rule monitors for the execution of several commonly used system commands ex *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-termination-of-esxi-process.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-termination-of-esxi-process.asciidoc index cd9db9eb0d..9f1a740f5d 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-termination-of-esxi-process.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-termination-of-esxi-process.asciidoc @@ -40,6 +40,38 @@ Identifies instances where VMware processes, such as "vmware-vmx" or "vmx," are *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-utility-launched-via-proxychains.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-utility-launched-via-proxychains.asciidoc index 097bcdbcab..d5e86018ea 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-utility-launched-via-proxychains.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-utility-launched-via-proxychains.asciidoc @@ -54,8 +54,8 @@ Attackers can leverage `proxychains` to obfuscate their origin and bypass networ This rule looks for a list of suspicious processes spawned through `proxychains` by analyzing process command line arguments. > **Note**: -> This investigation guide uses the {security-guide}/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. -> This investigation guide uses {security-guide}/security/current/osquery-placeholder-fields.html[placeholder fields] to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. +> This investigation guide uses https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run. #### Possible investigation steps @@ -110,6 +110,36 @@ This rule looks for a list of suspicious processes spawned through `proxychains` ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +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. + +#### 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. +- 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. +- 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. + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-werfault-child-process.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-werfault-child-process.asciidoc index 910d68b205..7dcda1af7f 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-werfault-child-process.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-werfault-child-process.asciidoc @@ -49,6 +49,20 @@ A suspicious WerFault child process was detected, which may indicate an attempt *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-windows-process-cluster-spawned-by-a-host.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-windows-process-cluster-spawned-by-a-host.asciidoc index b5794bf02a..53a809291c 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-windows-process-cluster-spawned-by-a-host.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-windows-process-cluster-spawned-by-a-host.asciidoc @@ -39,6 +39,66 @@ A machine learning job combination has detected a set of one or more suspicious *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- +The rule requires the Living off the Land (LotL) Attack Detection integration assets to be installed, as well as Windows process events collected by integrations such as Elastic Defend or Winlogbeat. + +### LotL Attack Detection Setup +The LotL Attack Detection integration detects living-off-the-land activity in Windows process events. + +#### Prerequisite Requirements: +- Fleet is required for LotL Attack Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html. +- Windows process events collected by the https://docs.elastic.co/en/integrations/endpoint integration or Winlogbeat(https://www.elastic.co/guide/en/beats/winlogbeat/current/_winlogbeat_overview.html). +- To install Elastic Defend, refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html. +- To set up and run Winlogbeat, follow https://www.elastic.co/guide/en/beats/winlogbeat/current/winlogbeat-installation-configuration.html guide. + +#### The following steps should be executed to install assets associated with the LotL Attack Detection integration: +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Living off the Land Attack Detection and select the integration to see more details about it. +- Under Settings, click Install Living off the Land Attack Detection assets and follow the prompts to install the assets. + +#### Ingest Pipeline Setup +Before you can enable this rule, you'll need to enrich Windows process events with predictions from the Supervised LotL Attack Detection model. This is done via the ingest pipeline named `-problem_child_ingest_pipeline` installed with the LotL Attack Detection package. +- If using an Elastic Beat such as Winlogbeat, add the LotL ingest pipeline to it by adding a simple configuration https://www.elastic.co/guide/en/elasticsearch/reference/current/ingest.html#pipelines-for-beats to `winlogbeat.yml`. +- If adding the LotL ingest pipeline to an existing pipeline, use a https://www.elastic.co/guide/en/elasticsearch/reference/current/pipeline-processor.html. + +#### Adding Custom Mappings +- Go to the Kibana homepage. Under Management, click Stack Management. +- Under Data click Index Management and navigate to the Component Templates tab. +- Templates that can be edited to add custom components will be marked with a @custom suffix. Edit the @custom component template corresponding to the beat/integration you added the LotL ingest pipeline to, by pasting the following JSON blob in the "Load JSON" flyout: +``` +{ + "properties": { + "problemchild": { + "properties": { + "prediction": { + "type": "long" + }, + "prediction_probability": { + "type": "float" + } + } + }, + "blocklist_label": { + "type": "long" + } + } +} +``` + +### Anomaly Detection Setup +Before you can enable this rule, you'll need to enable the corresponding Anomaly Detection job. +- Go to the Kibana homepage. Under Analytics, click Machine Learning. +- Under Anomaly Detection, click Jobs, and then click "Create job". Select the Data View containing your enriched Windows process events. For example, this would be `logs-endpoint.events.*` if you used Elastic Defend to collect events, or `winlogbeat-*` if you used Winlogbeat. +- If the selected Data View contains events that match the query in https://github.com/elastic/integrations/blob/main/packages/problemchild/kibana/ml_module/problemchild-ml.json configuration file, you will see a card for "Living off the Land Attack Detection" under "Use preconfigured jobs". +- Keep the default settings and click "Create jobs" to start the anomaly detection job and datafeed. + +---------------------------------- + *Framework*: MITRE ATT&CK^TM^ * Tactic: diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-windows-process-cluster-spawned-by-a-parent-process.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-windows-process-cluster-spawned-by-a-parent-process.asciidoc index a4e165a3ec..94fad6cf77 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-windows-process-cluster-spawned-by-a-parent-process.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-windows-process-cluster-spawned-by-a-parent-process.asciidoc @@ -41,6 +41,66 @@ A machine learning job combination has detected a set of one or more suspicious *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- +The rule requires the Living off the Land (LotL) Attack Detection integration assets to be installed, as well as Windows process events collected by integrations such as Elastic Defend or Winlogbeat. + +### LotL Attack Detection Setup +The LotL Attack Detection integration detects living-off-the-land activity in Windows process events. + +#### Prerequisite Requirements: +- Fleet is required for LotL Attack Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html. +- Windows process events collected by the https://docs.elastic.co/en/integrations/endpoint integration or Winlogbeat(https://www.elastic.co/guide/en/beats/winlogbeat/current/_winlogbeat_overview.html). +- To install Elastic Defend, refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html. +- To set up and run Winlogbeat, follow https://www.elastic.co/guide/en/beats/winlogbeat/current/winlogbeat-installation-configuration.html guide. + +#### The following steps should be executed to install assets associated with the LotL Attack Detection integration: +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Living off the Land Attack Detection and select the integration to see more details about it. +- Under Settings, click Install Living off the Land Attack Detection assets and follow the prompts to install the assets. + +#### Ingest Pipeline Setup +Before you can enable this rule, you'll need to enrich Windows process events with predictions from the Supervised LotL Attack Detection model. This is done via the ingest pipeline named `-problem_child_ingest_pipeline` installed with the LotL Attack Detection package. +- If using an Elastic Beat such as Winlogbeat, add the LotL ingest pipeline to it by adding a simple configuration https://www.elastic.co/guide/en/elasticsearch/reference/current/ingest.html#pipelines-for-beats to `winlogbeat.yml`. +- If adding the LotL ingest pipeline to an existing pipeline, use a https://www.elastic.co/guide/en/elasticsearch/reference/current/pipeline-processor.html. + +#### Adding Custom Mappings +- Go to the Kibana homepage. Under Management, click Stack Management. +- Under Data click Index Management and navigate to the Component Templates tab. +- Templates that can be edited to add custom components will be marked with a @custom suffix. Edit the @custom component template corresponding to the beat/integration you added the LotL ingest pipeline to, by pasting the following JSON blob in the "Load JSON" flyout: +``` +{ + "properties": { + "problemchild": { + "properties": { + "prediction": { + "type": "long" + }, + "prediction_probability": { + "type": "float" + } + } + }, + "blocklist_label": { + "type": "long" + } + } +} +``` + +### Anomaly Detection Setup +Before you can enable this rule, you'll need to enable the corresponding Anomaly Detection job. +- Go to the Kibana homepage. Under Analytics, click Machine Learning. +- Under Anomaly Detection, click Jobs, and then click "Create job". Select the Data View containing your enriched Windows process events. For example, this would be `logs-endpoint.events.*` if you used Elastic Defend to collect events, or `winlogbeat-*` if you used Winlogbeat. +- If the selected Data View contains events that match the query in https://github.com/elastic/integrations/blob/main/packages/problemchild/kibana/ml_module/problemchild-ml.json configuration file, you will see a card for "Living off the Land Attack Detection" under "Use preconfigured jobs". +- Keep the default settings and click "Create jobs" to start the anomaly detection job and datafeed. + +---------------------------------- + *Framework*: MITRE ATT&CK^TM^ * Tactic: diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-windows-process-cluster-spawned-by-a-user.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-windows-process-cluster-spawned-by-a-user.asciidoc index 3c044a9136..6d61d8192c 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-windows-process-cluster-spawned-by-a-user.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-windows-process-cluster-spawned-by-a-user.asciidoc @@ -41,6 +41,66 @@ A machine learning job combination has detected a set of one or more suspicious *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- +The rule requires the Living off the Land (LotL) Attack Detection integration assets to be installed, as well as Windows process events collected by integrations such as Elastic Defend or Winlogbeat. + +### LotL Attack Detection Setup +The LotL Attack Detection integration detects living-off-the-land activity in Windows process events. + +#### Prerequisite Requirements: +- Fleet is required for LotL Attack Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html. +- Windows process events collected by the https://docs.elastic.co/en/integrations/endpoint integration or Winlogbeat(https://www.elastic.co/guide/en/beats/winlogbeat/current/_winlogbeat_overview.html). +- To install Elastic Defend, refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html. +- To set up and run Winlogbeat, follow https://www.elastic.co/guide/en/beats/winlogbeat/current/winlogbeat-installation-configuration.html guide. + +#### The following steps should be executed to install assets associated with the LotL Attack Detection integration: +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Living off the Land Attack Detection and select the integration to see more details about it. +- Under Settings, click Install Living off the Land Attack Detection assets and follow the prompts to install the assets. + +#### Ingest Pipeline Setup +Before you can enable this rule, you'll need to enrich Windows process events with predictions from the Supervised LotL Attack Detection model. This is done via the ingest pipeline named `-problem_child_ingest_pipeline` installed with the LotL Attack Detection package. +- If using an Elastic Beat such as Winlogbeat, add the LotL ingest pipeline to it by adding a simple configuration https://www.elastic.co/guide/en/elasticsearch/reference/current/ingest.html#pipelines-for-beats to `winlogbeat.yml`. +- If adding the LotL ingest pipeline to an existing pipeline, use a https://www.elastic.co/guide/en/elasticsearch/reference/current/pipeline-processor.html. + +#### Adding Custom Mappings +- Go to the Kibana homepage. Under Management, click Stack Management. +- Under Data click Index Management and navigate to the Component Templates tab. +- Templates that can be edited to add custom components will be marked with a @custom suffix. Edit the @custom component template corresponding to the beat/integration you added the LotL ingest pipeline to, by pasting the following JSON blob in the "Load JSON" flyout: +``` +{ + "properties": { + "problemchild": { + "properties": { + "prediction": { + "type": "long" + }, + "prediction_probability": { + "type": "float" + } + } + }, + "blocklist_label": { + "type": "long" + } + } +} +``` + +### Anomaly Detection Setup +Before you can enable this rule, you'll need to enable the corresponding Anomaly Detection job. +- Go to the Kibana homepage. Under Analytics, click Machine Learning. +- Under Anomaly Detection, click Jobs, and then click "Create job". Select the Data View containing your enriched Windows process events. For example, this would be `logs-endpoint.events.*` if you used Elastic Defend to collect events, or `winlogbeat-*` if you used Winlogbeat. +- If the selected Data View contains events that match the query in https://github.com/elastic/integrations/blob/main/packages/problemchild/kibana/ml_module/problemchild-ml.json configuration file, you will see a card for "Living off the Land Attack Detection" under "Use preconfigured jobs". +- Keep the default settings and click "Create jobs" to start the anomaly detection job and datafeed. + +---------------------------------- + *Framework*: MITRE ATT&CK^TM^ * Tactic: diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-wmi-image-load-from-ms-office.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-wmi-image-load-from-ms-office.asciidoc index 71321bcd6f..3035f66a0c 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-wmi-image-load-from-ms-office.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-wmi-image-load-from-ms-office.asciidoc @@ -44,6 +44,20 @@ Identifies a suspicious image load (wmiutils.dll) from Microsoft Office processe *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/suspicious-zoom-child-process.asciidoc b/docs/detections/prebuilt-rules/rule-details/suspicious-zoom-child-process.asciidoc index 5305137091..c21100dd25 100644 --- a/docs/detections/prebuilt-rules/rule-details/suspicious-zoom-child-process.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/suspicious-zoom-child-process.asciidoc @@ -58,7 +58,7 @@ By examining the specific traits of Windows binaries -- such as process trees, c This rule identifies a potential malicious process masquerading as `Zoom.exe` or exploiting a vulnerability in the application causing it to execute code. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps diff --git a/docs/detections/prebuilt-rules/rule-details/svchost-spawning-cmd.asciidoc b/docs/detections/prebuilt-rules/rule-details/svchost-spawning-cmd.asciidoc index fc3feb380e..1ed3bcd5e0 100644 --- a/docs/detections/prebuilt-rules/rule-details/svchost-spawning-cmd.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/svchost-spawning-cmd.asciidoc @@ -58,7 +58,7 @@ The Service Host process (SvcHost) is a system process that can host one, or mul This rule looks for the creation of the `cmd.exe` process with `svchost.exe` as its parent process. This is an unusual behavior that can indicate the masquerading of a malicious process as `svchost.exe` or exploitation for privilege escalation. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps @@ -100,6 +100,20 @@ This rule looks for the creation of the `cmd.exe` process with `svchost.exe` as - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/symbolic-link-to-shadow-copy-created.asciidoc b/docs/detections/prebuilt-rules/rule-details/symbolic-link-to-shadow-copy-created.asciidoc index ac9051e1db..46ed2a03e3 100644 --- a/docs/detections/prebuilt-rules/rule-details/symbolic-link-to-shadow-copy-created.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/symbolic-link-to-shadow-copy-created.asciidoc @@ -93,6 +93,38 @@ Shadow copies are backups or snapshots of an endpoint's files or volumes while t - 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 + + +[source, markdown] +---------------------------------- + +Ensure advanced audit policies for Windows are enabled, specifically: +Object Access policies https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4656 (Handle to an Object was Requested) + +``` +Computer Configuration > +Policies > +Windows Settings > +Security Settings > +Advanced Audit Policies Configuration > +System Audit Policies > +Object Access > +Audit File System (Success,Failure) +Audit Handle Manipulation (Success,Failure) +``` + +This event will only trigger if symbolic links are created from a new process spawning cmd.exe or powershell.exe with the correct arguments. +Direct access to a shell and calling symbolic link creation tools will not generate an event matching this rule. + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/system-binary-copied-and-or-moved-to-suspicious-directory.asciidoc b/docs/detections/prebuilt-rules/rule-details/system-binary-copied-and-or-moved-to-suspicious-directory.asciidoc index 6577022bf6..55bef1f8ff 100644 --- a/docs/detections/prebuilt-rules/rule-details/system-binary-copied-and-or-moved-to-suspicious-directory.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/system-binary-copied-and-or-moved-to-suspicious-directory.asciidoc @@ -38,6 +38,38 @@ This rule monitors for the copying or moving of a system binary to a suspicious *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/system-information-discovery-via-windows-command-shell.asciidoc b/docs/detections/prebuilt-rules/rule-details/system-information-discovery-via-windows-command-shell.asciidoc index 780a71b63b..e63a721faa 100644 --- a/docs/detections/prebuilt-rules/rule-details/system-information-discovery-via-windows-command-shell.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/system-information-discovery-via-windows-command-shell.asciidoc @@ -76,6 +76,21 @@ This rule identifies commands to enumerate system information, files, and folder - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/system-log-file-deletion.asciidoc b/docs/detections/prebuilt-rules/rule-details/system-log-file-deletion.asciidoc index f3b5d02f3d..4ed40cc38f 100644 --- a/docs/detections/prebuilt-rules/rule-details/system-log-file-deletion.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/system-log-file-deletion.asciidoc @@ -43,6 +43,53 @@ Identifies the deletion of sensitive Linux system logs. This may indicate an att *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Auditbeat + +### 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. + +#### 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. +- 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. +- 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. + +### Auditbeat Setup +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + +#### The following steps should be executed in order to add the Auditbeat on a Linux System: +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html. + +#### Custom Ingest Pipeline +For versions <8.2, you need to add a custom ingest pipeline to populate `event.ingested` with @timestamp for non-elastic-agent indexes, like auditbeats/filebeat/winlogbeat etc. For more details to add a custom ingest pipeline refer to the https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/system-shells-via-services.asciidoc b/docs/detections/prebuilt-rules/rule-details/system-shells-via-services.asciidoc index 52a3cb5e66..d81cbe48e1 100644 --- a/docs/detections/prebuilt-rules/rule-details/system-shells-via-services.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/system-shells-via-services.asciidoc @@ -59,7 +59,7 @@ Attackers may configure existing services or create new ones to execute system s This rule looks for system shells being spawned by `services.exe`, which is compatible with the above behavior. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps diff --git a/docs/detections/prebuilt-rules/rule-details/systemkey-access-via-command-line.asciidoc b/docs/detections/prebuilt-rules/rule-details/systemkey-access-via-command-line.asciidoc index 3c4b2622fa..df1ee225b5 100644 --- a/docs/detections/prebuilt-rules/rule-details/systemkey-access-via-command-line.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/systemkey-access-via-command-line.asciidoc @@ -40,6 +40,38 @@ Keychains are the built-in way for macOS to keep track of users' passwords and c *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### The following steps should be executed in order to add the Elastic Defend integration on a macOS 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, for MacOS it is recommended to select "Traditional Endpoints". +- 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/tainted-kernel-module-load.asciidoc b/docs/detections/prebuilt-rules/rule-details/tainted-kernel-module-load.asciidoc index 032dcb1e9e..73311093db 100644 --- a/docs/detections/prebuilt-rules/rule-details/tainted-kernel-module-load.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/tainted-kernel-module-load.asciidoc @@ -39,6 +39,34 @@ This rule monitors the syslog log file for messages related to instances of a ta *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +This rule requires data coming in from one of the following integrations: +- Filebeat + +### Filebeat Setup +Filebeat is a lightweight shipper for forwarding and centralizing log data. Installed as an agent on your servers, Filebeat monitors the log files or locations that you specify, collects log events, and forwards them either to Elasticsearch or Logstash for indexing. + +#### The following steps should be executed in order to add the Filebeat for the Linux System: +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/filebeat/current/setup-repositories.html. +- To run Filebeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/running-on-docker.html. +- To run Filebeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/running-on-kubernetes.html. +- For quick start information for Filebeat refer to the https://www.elastic.co/guide/en/beats/filebeat/8.11/filebeat-installation-configuration.html. +- For complete Setup and Run Filebeat information refer to the https://www.elastic.co/guide/en/beats/filebeat/current/setting-up-and-running.html. + +#### Rule Specific Setup Note +- This rule requires the Filebeat System Module to be enabled. +- The system module collects and parses logs created by the system logging service of common Unix/Linux based distributions. +- To run the system module of Filebeat on Linux follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-system.html. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/tainted-out-of-tree-kernel-module-load.asciidoc b/docs/detections/prebuilt-rules/rule-details/tainted-out-of-tree-kernel-module-load.asciidoc index cefeb102b8..e930fe46e0 100644 --- a/docs/detections/prebuilt-rules/rule-details/tainted-out-of-tree-kernel-module-load.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/tainted-out-of-tree-kernel-module-load.asciidoc @@ -39,6 +39,34 @@ This rule monitors the syslog log file for messages related to instances of a ou *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- +## Setup + +This rule requires data coming in from one of the following integrations: +- Filebeat + +### Filebeat Setup +Filebeat is a lightweight shipper for forwarding and centralizing log data. Installed as an agent on your servers, Filebeat monitors the log files or locations that you specify, collects log events, and forwards them either to Elasticsearch or Logstash for indexing. + +#### The following steps should be executed in order to add the Filebeat for the Linux System: +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/filebeat/current/setup-repositories.html. +- To run Filebeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/running-on-docker.html. +- To run Filebeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/running-on-kubernetes.html. +- For quick start information for Filebeat refer to the https://www.elastic.co/guide/en/beats/filebeat/8.11/filebeat-installation-configuration.html. +- For complete Setup and Run Filebeat information refer to the https://www.elastic.co/guide/en/beats/filebeat/current/setting-up-and-running.html. + +#### Rule Specific Setup Note +- This rule requires the Filebeat System Module to be enabled. +- The system module collects and parses logs created by the system logging service of common Unix/Linux based distributions. +- To run the system module of Filebeat on Linux follow the setup instructions in the https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-system.html. + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/tampering-of-bash-command-line-history.asciidoc b/docs/detections/prebuilt-rules/rule-details/tampering-of-bash-command-line-history.asciidoc index dc80ede4f9..a3b9327f30 100644 --- a/docs/detections/prebuilt-rules/rule-details/tampering-of-bash-command-line-history.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/tampering-of-bash-command-line-history.asciidoc @@ -40,6 +40,20 @@ Adversaries may attempt to clear or disable the Bash command-line history in an *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/tcc-bypass-via-mounted-apfs-snapshot-access.asciidoc b/docs/detections/prebuilt-rules/rule-details/tcc-bypass-via-mounted-apfs-snapshot-access.asciidoc index 8fe690c214..c116d28364 100644 --- a/docs/detections/prebuilt-rules/rule-details/tcc-bypass-via-mounted-apfs-snapshot-access.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/tcc-bypass-via-mounted-apfs-snapshot-access.asciidoc @@ -41,6 +41,38 @@ Identifies the use of the mount_apfs command to mount the entire file system thr *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### The following steps should be executed in order to add the Elastic Defend integration on a macOS 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, for MacOS it is recommended to select "Traditional Endpoints". +- 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/third-party-backup-files-deleted-via-unexpected-process.asciidoc b/docs/detections/prebuilt-rules/rule-details/third-party-backup-files-deleted-via-unexpected-process.asciidoc index 41b2b2473c..27453f5ef6 100644 --- a/docs/detections/prebuilt-rules/rule-details/third-party-backup-files-deleted-via-unexpected-process.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/third-party-backup-files-deleted-via-unexpected-process.asciidoc @@ -90,6 +90,20 @@ This rule identifies file deletions performed by a process that does not belong - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query 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 4f9549bedf..65d7304b2a 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 @@ -60,7 +60,7 @@ Matches are based on threat intelligence data that's been ingested during the la 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 {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps @@ -104,6 +104,21 @@ This rule is triggered when a hash indicator from the Threat Intel Filebeat modu - 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 + + +[source, markdown] +---------------------------------- + +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, +the https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html#ti-mod-integration, +or a https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html#custom-ti-integration. + +More information can be found https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html. + ---------------------------------- ==== Rule query 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 1a23ad67ae..3fabd4e849 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 @@ -61,7 +61,7 @@ Matches are based on threat intelligence data that's been ingested during the la 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 {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps @@ -106,6 +106,21 @@ This rule is triggered when an IP address indicator from the Threat Intel Filebe - 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 + + +[source, markdown] +---------------------------------- + +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, +the https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html#ti-mod-integration, +or a https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html#custom-ti-integration. + +More information can be found https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html. + ---------------------------------- ==== Rule query 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 09b55a22c4..7ffb7805ff 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 @@ -61,7 +61,7 @@ Matches are based on threat intelligence data that's been ingested during the la 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 {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps @@ -109,6 +109,21 @@ This rule is triggered when a URL indicator from the Threat Intel Filebeat modul - 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 + + +[source, markdown] +---------------------------------- + +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, +the https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html#ti-mod-integration, +or a https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html#custom-ti-integration. + +More information can be found https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html. + ---------------------------------- ==== Rule query 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 f128cfdc7d..b01e9f5c31 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 @@ -60,7 +60,7 @@ Matches are based on threat intelligence data that's been ingested during the la 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 {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps @@ -99,6 +99,21 @@ This rule is triggered when a Windows registry indicator from the Threat Intel F - 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 + + +[source, markdown] +---------------------------------- + +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, +the https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html#ti-mod-integration, +or a https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html#custom-ti-integration. + +More information can be found https://www.elastic.co/guide/en/security/current/es-threat-intel-integrations.html. + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/timestomping-using-touch-command.asciidoc b/docs/detections/prebuilt-rules/rule-details/timestomping-using-touch-command.asciidoc index 1084901ea4..39c5207011 100644 --- a/docs/detections/prebuilt-rules/rule-details/timestomping-using-touch-command.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/timestomping-using-touch-command.asciidoc @@ -40,6 +40,20 @@ Timestomping is an anti-forensics technique which is used to modify the timestam *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/uac-bypass-attempt-via-elevated-com-internet-explorer-add-on-installer.asciidoc b/docs/detections/prebuilt-rules/rule-details/uac-bypass-attempt-via-elevated-com-internet-explorer-add-on-installer.asciidoc index 5146009c3f..58938920dc 100644 --- a/docs/detections/prebuilt-rules/rule-details/uac-bypass-attempt-via-elevated-com-internet-explorer-add-on-installer.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/uac-bypass-attempt-via-elevated-com-internet-explorer-add-on-installer.asciidoc @@ -46,6 +46,20 @@ Identifies User Account Control (UAC) bypass attempts by abusing an elevated COM *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/uac-bypass-attempt-via-privileged-ifileoperation-com-interface.asciidoc b/docs/detections/prebuilt-rules/rule-details/uac-bypass-attempt-via-privileged-ifileoperation-com-interface.asciidoc index e59d0490c0..8a181a61cd 100644 --- a/docs/detections/prebuilt-rules/rule-details/uac-bypass-attempt-via-privileged-ifileoperation-com-interface.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/uac-bypass-attempt-via-privileged-ifileoperation-com-interface.asciidoc @@ -46,6 +46,20 @@ Identifies attempts to bypass User Account Control (UAC) via DLL side-loading. A *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/uac-bypass-attempt-via-windows-directory-masquerading.asciidoc b/docs/detections/prebuilt-rules/rule-details/uac-bypass-attempt-via-windows-directory-masquerading.asciidoc index ad1d1c5525..427e73779e 100644 --- a/docs/detections/prebuilt-rules/rule-details/uac-bypass-attempt-via-windows-directory-masquerading.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/uac-bypass-attempt-via-windows-directory-masquerading.asciidoc @@ -58,12 +58,12 @@ Identifies an attempt to bypass User Account Control (UAC) by masquerading as a Windows User Account Control (UAC) allows a program to elevate its privileges (tracked as low to high integrity levels) to perform a task under administrator-level permissions, possibly by prompting the user for confirmation. UAC can deny an operation under high-integrity enforcement, or allow the user to perform the action if they are in the local administrators group and enter an administrator password when prompted. -For more information about the UAC and how it works, check the [official Microsoft docs page](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/how-user-account-control-works). +For more information about the UAC and how it works, check the https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/how-user-account-control-works. This rule identifies an attempt to bypass User Account Control (UAC) by masquerading as a Microsoft trusted Windows directory. Attackers may bypass UAC to stealthily execute code with elevated permissions. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps @@ -106,6 +106,20 @@ This rule identifies an attempt to bypass User Account Control (UAC) by masquera - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/uac-bypass-attempt-with-ieditionupgrademanager-elevated-com-interface.asciidoc b/docs/detections/prebuilt-rules/rule-details/uac-bypass-attempt-with-ieditionupgrademanager-elevated-com-interface.asciidoc index f59b4006fe..131fd0999a 100644 --- a/docs/detections/prebuilt-rules/rule-details/uac-bypass-attempt-with-ieditionupgrademanager-elevated-com-interface.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/uac-bypass-attempt-with-ieditionupgrademanager-elevated-com-interface.asciidoc @@ -46,6 +46,20 @@ Identifies attempts to bypass User Account Control (UAC) by abusing an elevated *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/uac-bypass-via-diskcleanup-scheduled-task-hijack.asciidoc b/docs/detections/prebuilt-rules/rule-details/uac-bypass-via-diskcleanup-scheduled-task-hijack.asciidoc index 695a7cfaf6..4d52de8d19 100644 --- a/docs/detections/prebuilt-rules/rule-details/uac-bypass-via-diskcleanup-scheduled-task-hijack.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/uac-bypass-via-diskcleanup-scheduled-task-hijack.asciidoc @@ -45,6 +45,20 @@ Identifies User Account Control (UAC) bypass via hijacking DiskCleanup Scheduled *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/uac-bypass-via-icmluautil-elevated-com-interface.asciidoc b/docs/detections/prebuilt-rules/rule-details/uac-bypass-via-icmluautil-elevated-com-interface.asciidoc index 1b7a089145..3cb365a188 100644 --- a/docs/detections/prebuilt-rules/rule-details/uac-bypass-via-icmluautil-elevated-com-interface.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/uac-bypass-via-icmluautil-elevated-com-interface.asciidoc @@ -44,6 +44,20 @@ Identifies User Account Control (UAC) bypass attempts via the ICMLuaUtil Elevate *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/uac-bypass-via-windows-firewall-snap-in-hijack.asciidoc b/docs/detections/prebuilt-rules/rule-details/uac-bypass-via-windows-firewall-snap-in-hijack.asciidoc index 3894575b12..dfa56fd7c3 100644 --- a/docs/detections/prebuilt-rules/rule-details/uac-bypass-via-windows-firewall-snap-in-hijack.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/uac-bypass-via-windows-firewall-snap-in-hijack.asciidoc @@ -57,12 +57,12 @@ Identifies attempts to bypass User Account Control (UAC) by hijacking the Micros Windows User Account Control (UAC) allows a program to elevate its privileges (tracked as low to high integrity levels) to perform a task under administrator-level permissions, possibly by prompting the user for confirmation. UAC can deny an operation under high-integrity enforcement, or allow the user to perform the action if they are in the local administrators group and enter an administrator password when prompted. -For more information about the UAC and how it works, check the [official Microsoft docs page](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/how-user-account-control-works). +For more information about the UAC and how it works, check the https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/how-user-account-control-works. This rule identifies attempts to bypass User Account Control (UAC) by hijacking the Microsoft Management Console (MMC) Windows Firewall snap-in. Attackers bypass UAC to stealthily execute code with elevated permissions. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps @@ -105,6 +105,20 @@ This rule identifies attempts to bypass User Account Control (UAC) by hijacking - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/uid-elevation-from-previously-unknown-executable.asciidoc b/docs/detections/prebuilt-rules/rule-details/uid-elevation-from-previously-unknown-executable.asciidoc index 255c21e288..b7cea08a9e 100644 --- a/docs/detections/prebuilt-rules/rule-details/uid-elevation-from-previously-unknown-executable.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/uid-elevation-from-previously-unknown-executable.asciidoc @@ -39,6 +39,39 @@ Monitors for the elevation of regular user permissions to root permissions throu *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- +## 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. + +#### 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. +- We suggest to select "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. +- 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. + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/unauthorized-access-to-an-okta-application.asciidoc b/docs/detections/prebuilt-rules/rule-details/unauthorized-access-to-an-okta-application.asciidoc index cac33af7ed..00ec7e961b 100644 --- a/docs/detections/prebuilt-rules/rule-details/unauthorized-access-to-an-okta-application.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unauthorized-access-to-an-okta-application.asciidoc @@ -50,6 +50,14 @@ Identifies unauthorized access attempts to Okta applications. ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/unexpected-child-process-of-macos-screensaver-engine.asciidoc b/docs/detections/prebuilt-rules/rule-details/unexpected-child-process-of-macos-screensaver-engine.asciidoc index 0ccbd393d9..e2645c4cfb 100644 --- a/docs/detections/prebuilt-rules/rule-details/unexpected-child-process-of-macos-screensaver-engine.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unexpected-child-process-of-macos-screensaver-engine.asciidoc @@ -54,6 +54,38 @@ as a download of a payload from a server. identify whether the file is malicious or not. +---------------------------------- + +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### The following steps should be executed in order to add the Elastic Defend integration on a macOS 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, for MacOS it is recommended to select "Traditional Endpoints". +- 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. +- 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. +- 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. + + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/unsigned-dll-side-loading-from-a-suspicious-folder.asciidoc b/docs/detections/prebuilt-rules/rule-details/unsigned-dll-side-loading-from-a-suspicious-folder.asciidoc index 9a835f92f9..e65e0ec40e 100644 --- a/docs/detections/prebuilt-rules/rule-details/unsigned-dll-side-loading-from-a-suspicious-folder.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unsigned-dll-side-loading-from-a-suspicious-folder.asciidoc @@ -38,6 +38,20 @@ Identifies a Windows trusted program running from locations often abused by adve *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/untrusted-driver-loaded.asciidoc b/docs/detections/prebuilt-rules/rule-details/untrusted-driver-loaded.asciidoc index 6eaa986b59..ff71f20184 100644 --- a/docs/detections/prebuilt-rules/rule-details/untrusted-driver-loaded.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/untrusted-driver-loaded.asciidoc @@ -58,7 +58,7 @@ This protection is essential for maintaining system security. However, attackers This rule identifies an attempt to load an untrusted driver, which effectively means that DSE was disabled or bypassed. This can indicate that the system was compromised. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps 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 c024ec36a1..f40dfd67f2 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 @@ -95,8 +95,16 @@ Detection alerts from this rule indicate an AWS API command or method call that - 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 [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS. +- Implement security best practices https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/ 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 + + +[source, markdown] +---------------------------------- +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-child-process-from-a-system-virtual-process.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-child-process-from-a-system-virtual-process.asciidoc index 9088b0d94c..99ffa6a380 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-child-process-from-a-system-virtual-process.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-child-process-from-a-system-virtual-process.asciidoc @@ -42,6 +42,20 @@ Identifies a suspicious child process of the Windows virtual system process, whi *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-child-process-of-dns-exe.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-child-process-of-dns-exe.asciidoc index bfdaa0b1ab..83f8365e1c 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-child-process-of-dns-exe.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-child-process-of-dns-exe.asciidoc @@ -91,6 +91,20 @@ This rule looks for unusual children of the `dns.exe` process, which can indicat - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-child-processes-of-rundll32.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-child-processes-of-rundll32.asciidoc index 34596e9b55..39c7f6ba75 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-child-processes-of-rundll32.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-child-processes-of-rundll32.asciidoc @@ -54,7 +54,7 @@ By examining the specific traits of Windows binaries -- such as process trees, c RunDLL32 is a legitimate Windows utility used to load and execute functions within dynamic-link libraries (DLLs). However, adversaries may abuse RunDLL32 to execute malicious code, bypassing security measures and evading detection. This rule identifies potential abuse by looking for an unusual process creation with no arguments followed by the creation of a child process. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. ### Possible investigation steps 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 e0b30db27b..6da2c5ad01 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 @@ -96,8 +96,16 @@ Detection alerts from this rule indicate an AWS API command or method call that - 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 [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS. +- Implement security best practices https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/ 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 + + +[source, markdown] +---------------------------------- +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- 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 bd103be201..efa8f468dd 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 @@ -96,8 +96,16 @@ Detection alerts from this rule indicate an AWS API command or method call that - 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 [outlined](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/) by AWS. +- Implement security best practices https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/ 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 + + +[source, markdown] +---------------------------------- +The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-executable-file-creation-by-a-system-critical-process.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-executable-file-creation-by-a-system-critical-process.asciidoc index a87a6ad71e..805bff2f16 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-executable-file-creation-by-a-system-critical-process.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-executable-file-creation-by-a-system-critical-process.asciidoc @@ -58,7 +58,7 @@ Windows internal/system processes have some characteristics that can be used to This rule looks for the creation of executable files done by system-critical processes. This can indicate the exploitation of a vulnerability or a malicious process masquerading as a system-critical process. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps @@ -100,6 +100,20 @@ This rule looks for the creation of executable files done by system-critical pro - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-file-creation-alternate-data-stream.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-file-creation-alternate-data-stream.asciidoc index c90ae1b321..e3ac0ac045 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-file-creation-alternate-data-stream.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-file-creation-alternate-data-stream.asciidoc @@ -57,7 +57,7 @@ The regular data stream, also referred to as the unnamed data stream since the n Attackers can abuse these alternate data streams to hide malicious files, string payloads, etc. This rule detects the creation of alternate data streams on highly targeted file types. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps @@ -103,6 +103,20 @@ Attackers can abuse these alternate data streams to hide malicious files, string - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-file-modification-by-dns-exe.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-file-modification-by-dns-exe.asciidoc index abf8cedfab..2f4236d593 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-file-modification-by-dns-exe.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-file-modification-by-dns-exe.asciidoc @@ -60,6 +60,20 @@ Detection alerts from this rule indicate potential unusual/abnormal file writes - Any suspicious or abnormal files written from `dns.exe` should be reviewed and investigated with care. +---------------------------------- + +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-network-activity-from-a-windows-system-binary.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-network-activity-from-a-windows-system-binary.asciidoc index 5244aa03db..f46f2e7c61 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-network-activity-from-a-windows-system-binary.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-network-activity-from-a-windows-system-binary.asciidoc @@ -55,7 +55,7 @@ Attackers can abuse certain trusted developer utilities to proxy the execution o This rule identifies network connections established by trusted developer utilities, which can indicate abuse to execute payloads or process masquerading. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-parent-child-relationship.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-parent-child-relationship.asciidoc index 3564a3c19e..c32606930f 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-parent-child-relationship.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-parent-child-relationship.asciidoc @@ -61,7 +61,7 @@ Windows internal/system processes have some characteristics that can be used to This rule uses this information to spot suspicious parent and child processes. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps @@ -103,6 +103,20 @@ This rule uses this information to spot suspicious parent and child processes. - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-parent-process-for-cmd-exe.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-parent-process-for-cmd-exe.asciidoc index 7037757657..1048a0d15c 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-parent-process-for-cmd-exe.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-parent-process-for-cmd-exe.asciidoc @@ -42,6 +42,20 @@ Identifies a suspicious parent child process relationship with cmd.exe descendin *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-print-spooler-child-process.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-print-spooler-child-process.asciidoc index cbcbd00749..b0af0dc2a0 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-print-spooler-child-process.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-print-spooler-child-process.asciidoc @@ -44,6 +44,20 @@ Detects unusual Print Spooler service (spoolsv.exe) child processes. This may in *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-process-execution-path-alternate-data-stream.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-process-execution-path-alternate-data-stream.asciidoc index d042b6a730..2836b05c8a 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-process-execution-path-alternate-data-stream.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-process-execution-path-alternate-data-stream.asciidoc @@ -43,6 +43,20 @@ Identifies processes running from an Alternate Data Stream. This is uncommon for *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query 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 1b251b68e7..00329059f0 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 @@ -54,7 +54,7 @@ Searching for abnormal Windows processes is a good methodology to find potential 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 {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-process-spawned-by-a-host.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-process-spawned-by-a-host.asciidoc index 6144cfa63b..53a5bdebb2 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-process-spawned-by-a-host.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-process-spawned-by-a-host.asciidoc @@ -41,6 +41,66 @@ A machine learning job has detected a suspicious Windows process. This process h *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- +The rule requires the Living off the Land (LotL) Attack Detection integration assets to be installed, as well as Windows process events collected by integrations such as Elastic Defend or Winlogbeat. + +### LotL Attack Detection Setup +The LotL Attack Detection integration detects living-off-the-land activity in Windows process events. + +#### Prerequisite Requirements: +- Fleet is required for LotL Attack Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html. +- Windows process events collected by the https://docs.elastic.co/en/integrations/endpoint integration or Winlogbeat(https://www.elastic.co/guide/en/beats/winlogbeat/current/_winlogbeat_overview.html). +- To install Elastic Defend, refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html. +- To set up and run Winlogbeat, follow https://www.elastic.co/guide/en/beats/winlogbeat/current/winlogbeat-installation-configuration.html guide. + +#### The following steps should be executed to install assets associated with the LotL Attack Detection integration: +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Living off the Land Attack Detection and select the integration to see more details about it. +- Under Settings, click Install Living off the Land Attack Detection assets and follow the prompts to install the assets. + +#### Ingest Pipeline Setup +Before you can enable this rule, you'll need to enrich Windows process events with predictions from the Supervised LotL Attack Detection model. This is done via the ingest pipeline named `-problem_child_ingest_pipeline` installed with the LotL Attack Detection package. +- If using an Elastic Beat such as Winlogbeat, add the LotL ingest pipeline to it by adding a simple configuration https://www.elastic.co/guide/en/elasticsearch/reference/current/ingest.html#pipelines-for-beats to `winlogbeat.yml`. +- If adding the LotL ingest pipeline to an existing pipeline, use a https://www.elastic.co/guide/en/elasticsearch/reference/current/pipeline-processor.html. + +#### Adding Custom Mappings +- Go to the Kibana homepage. Under Management, click Stack Management. +- Under Data click Index Management and navigate to the Component Templates tab. +- Templates that can be edited to add custom components will be marked with a @custom suffix. Edit the @custom component template corresponding to the beat/integration you added the LotL ingest pipeline to, by pasting the following JSON blob in the "Load JSON" flyout: +``` +{ + "properties": { + "problemchild": { + "properties": { + "prediction": { + "type": "long" + }, + "prediction_probability": { + "type": "float" + } + } + }, + "blocklist_label": { + "type": "long" + } + } +} +``` + +### Anomaly Detection Setup +Before you can enable this rule, you'll need to enable the corresponding Anomaly Detection job. +- Go to the Kibana homepage. Under Analytics, click Machine Learning. +- Under Anomaly Detection, click Jobs, and then click "Create job". Select the Data View containing your enriched Windows process events. For example, this would be `logs-endpoint.events.*` if you used Elastic Defend to collect events, or `winlogbeat-*` if you used Winlogbeat. +- If the selected Data View contains events that match the query in https://github.com/elastic/integrations/blob/main/packages/problemchild/kibana/ml_module/problemchild-ml.json configuration file, you will see a card for "Living off the Land Attack Detection" under "Use preconfigured jobs". +- Keep the default settings and click "Create jobs" to start the anomaly detection job and datafeed. + +---------------------------------- + *Framework*: MITRE ATT&CK^TM^ * Tactic: diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-process-spawned-by-a-parent-process.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-process-spawned-by-a-parent-process.asciidoc index 49ef172bc0..395c7eb8f7 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-process-spawned-by-a-parent-process.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-process-spawned-by-a-parent-process.asciidoc @@ -41,6 +41,66 @@ A machine learning job has detected a suspicious Windows process. This process h *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- +The rule requires the Living off the Land (LotL) Attack Detection integration assets to be installed, as well as Windows process events collected by integrations such as Elastic Defend or Winlogbeat. + +### LotL Attack Detection Setup +The LotL Attack Detection integration detects living-off-the-land activity in Windows process events. + +#### Prerequisite Requirements: +- Fleet is required for LotL Attack Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html. +- Windows process events collected by the https://docs.elastic.co/en/integrations/endpoint integration or Winlogbeat(https://www.elastic.co/guide/en/beats/winlogbeat/current/_winlogbeat_overview.html). +- To install Elastic Defend, refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html. +- To set up and run Winlogbeat, follow https://www.elastic.co/guide/en/beats/winlogbeat/current/winlogbeat-installation-configuration.html guide. + +#### The following steps should be executed to install assets associated with the LotL Attack Detection integration: +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Living off the Land Attack Detection and select the integration to see more details about it. +- Under Settings, click Install Living off the Land Attack Detection assets and follow the prompts to install the assets. + +#### Ingest Pipeline Setup +Before you can enable this rule, you'll need to enrich Windows process events with predictions from the Supervised LotL Attack Detection model. This is done via the ingest pipeline named `-problem_child_ingest_pipeline` installed with the LotL Attack Detection package. +- If using an Elastic Beat such as Winlogbeat, add the LotL ingest pipeline to it by adding a simple configuration https://www.elastic.co/guide/en/elasticsearch/reference/current/ingest.html#pipelines-for-beats to `winlogbeat.yml`. +- If adding the LotL ingest pipeline to an existing pipeline, use a https://www.elastic.co/guide/en/elasticsearch/reference/current/pipeline-processor.html. + +#### Adding Custom Mappings +- Go to the Kibana homepage. Under Management, click Stack Management. +- Under Data click Index Management and navigate to the Component Templates tab. +- Templates that can be edited to add custom components will be marked with a @custom suffix. Edit the @custom component template corresponding to the beat/integration you added the LotL ingest pipeline to, by pasting the following JSON blob in the "Load JSON" flyout: +``` +{ + "properties": { + "problemchild": { + "properties": { + "prediction": { + "type": "long" + }, + "prediction_probability": { + "type": "float" + } + } + }, + "blocklist_label": { + "type": "long" + } + } +} +``` + +### Anomaly Detection Setup +Before you can enable this rule, you'll need to enable the corresponding Anomaly Detection job. +- Go to the Kibana homepage. Under Analytics, click Machine Learning. +- Under Anomaly Detection, click Jobs, and then click "Create job". Select the Data View containing your enriched Windows process events. For example, this would be `logs-endpoint.events.*` if you used Elastic Defend to collect events, or `winlogbeat-*` if you used Winlogbeat. +- If the selected Data View contains events that match the query in https://github.com/elastic/integrations/blob/main/packages/problemchild/kibana/ml_module/problemchild-ml.json configuration file, you will see a card for "Living off the Land Attack Detection" under "Use preconfigured jobs". +- Keep the default settings and click "Create jobs" to start the anomaly detection job and datafeed. + +---------------------------------- + *Framework*: MITRE ATT&CK^TM^ * Tactic: diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-process-spawned-by-a-user.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-process-spawned-by-a-user.asciidoc index 5b439f0079..1a73a6b139 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-process-spawned-by-a-user.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-process-spawned-by-a-user.asciidoc @@ -41,6 +41,66 @@ A machine learning job has detected a suspicious Windows process. This process h *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- +The rule requires the Living off the Land (LotL) Attack Detection integration assets to be installed, as well as Windows process events collected by integrations such as Elastic Defend or Winlogbeat. + +### LotL Attack Detection Setup +The LotL Attack Detection integration detects living-off-the-land activity in Windows process events. + +#### Prerequisite Requirements: +- Fleet is required for LotL Attack Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html. +- Windows process events collected by the https://docs.elastic.co/en/integrations/endpoint integration or Winlogbeat(https://www.elastic.co/guide/en/beats/winlogbeat/current/_winlogbeat_overview.html). +- To install Elastic Defend, refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html. +- To set up and run Winlogbeat, follow https://www.elastic.co/guide/en/beats/winlogbeat/current/winlogbeat-installation-configuration.html guide. + +#### The following steps should be executed to install assets associated with the LotL Attack Detection integration: +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Living off the Land Attack Detection and select the integration to see more details about it. +- Under Settings, click Install Living off the Land Attack Detection assets and follow the prompts to install the assets. + +#### Ingest Pipeline Setup +Before you can enable this rule, you'll need to enrich Windows process events with predictions from the Supervised LotL Attack Detection model. This is done via the ingest pipeline named `-problem_child_ingest_pipeline` installed with the LotL Attack Detection package. +- If using an Elastic Beat such as Winlogbeat, add the LotL ingest pipeline to it by adding a simple configuration https://www.elastic.co/guide/en/elasticsearch/reference/current/ingest.html#pipelines-for-beats to `winlogbeat.yml`. +- If adding the LotL ingest pipeline to an existing pipeline, use a https://www.elastic.co/guide/en/elasticsearch/reference/current/pipeline-processor.html. + +#### Adding Custom Mappings +- Go to the Kibana homepage. Under Management, click Stack Management. +- Under Data click Index Management and navigate to the Component Templates tab. +- Templates that can be edited to add custom components will be marked with a @custom suffix. Edit the @custom component template corresponding to the beat/integration you added the LotL ingest pipeline to, by pasting the following JSON blob in the "Load JSON" flyout: +``` +{ + "properties": { + "problemchild": { + "properties": { + "prediction": { + "type": "long" + }, + "prediction_probability": { + "type": "float" + } + } + }, + "blocklist_label": { + "type": "long" + } + } +} +``` + +### Anomaly Detection Setup +Before you can enable this rule, you'll need to enable the corresponding Anomaly Detection job. +- Go to the Kibana homepage. Under Analytics, click Machine Learning. +- Under Anomaly Detection, click Jobs, and then click "Create job". Select the Data View containing your enriched Windows process events. For example, this would be `logs-endpoint.events.*` if you used Elastic Defend to collect events, or `winlogbeat-*` if you used Winlogbeat. +- If the selected Data View contains events that match the query in https://github.com/elastic/integrations/blob/main/packages/problemchild/kibana/ml_module/problemchild-ml.json configuration file, you will see a card for "Living off the Land Attack Detection" under "Use preconfigured jobs". +- Keep the default settings and click "Create jobs" to start the anomaly detection job and datafeed. + +---------------------------------- + *Framework*: MITRE ATT&CK^TM^ * Tactic: diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-process-writing-data-to-an-external-device.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-process-writing-data-to-an-external-device.asciidoc index a9d6977dc9..74f7ce77bc 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-process-writing-data-to-an-external-device.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-process-writing-data-to-an-external-device.asciidoc @@ -39,6 +39,36 @@ A machine learning job has detected a rare process writing data to an external d *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- +The rule requires the Data Exfiltration Detection integration assets to be installed, as well as network and file events collected by integrations such as Elastic Defend and Network Packet Capture (for network events only). + +### Data Exfiltration Detection Setup +The Data Exfiltration Detection integration detects data exfiltration activity by identifying abnormalities in network and file events. Anomalies are detected using Elastic's Anomaly Detection feature. + +#### Prerequisite Requirements: +- Fleet is required for Data Exfiltration Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html. +- File events collected by the Elastic Defend integration. +- To install Elastic Defend, refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html. + +#### The following steps should be executed to install assets associated with the Data Exfiltration Detection integration: +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Data Exfiltration Detection and select the integration to see more details about it. +- Under Settings, click Install Data Exfiltration Detection assets and follow the prompts to install the assets. + +#### Anomaly Detection Setup +Before you can enable rules for Data Exfiltration Detection, you'll need to enable the corresponding Anomaly Detection jobs. +- Go to the Kibana homepage. Under Analytics, click Machine Learning. +- Under Anomaly Detection, click Jobs, and then click "Create job". Select the Data View containing your file events. For example, this would be `logs-endpoint.events.*` if you used Elastic Defend to collect events. +- If the selected Data View contains events that match the query in https://github.com/elastic/integrations/blob/main/packages/ded/kibana/ml_module/ded-ml.json configuration file, you will see a card for Data Exfiltration Detection under "Use preconfigured jobs". +- Keep the default settings and click "Create jobs" to start the anomaly detection jobs and datafeeds. + +---------------------------------- + *Framework*: MITRE ATT&CK^TM^ * Tactic: diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-remote-file-directory.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-remote-file-directory.asciidoc index 488972e552..6056b146d9 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-remote-file-directory.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-remote-file-directory.asciidoc @@ -40,6 +40,36 @@ An anomaly detection job has detected a remote file transfer on an unusual direc *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- +The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration. + +### Lateral Movement Detection Setup +The Lateral Movement Detection integration detects lateral movement activity by identifying abnormalities in file and Windows RDP events. Anomalies are detected using Elastic's Anomaly Detection feature. + +#### Prerequisite Requirements: +- Fleet is required for Lateral Movement Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html. +- File events collected by the https://docs.elastic.co/en/integrations/endpoint integration. +- To install Elastic Defend, refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html. + +#### The following steps should be executed to install assets associated with the Lateral Movement Detection integration: +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Lateral Movement Detection and select the integration to see more details about it. +- Under Settings, click Install Lateral Movement Detection assets and follow the prompts to install the assets. + +#### Anomaly Detection Setup +Before you can enable rules for Lateral Movement Detection, you'll need to enable the corresponding Anomaly Detection jobs. +- Go to the Kibana homepage. Under Analytics, click Machine Learning. +- Under Anomaly Detection, click Jobs, and then click "Create job". Select the Data View containing your file events. For example, this would be `logs-endpoint.events.*` if you used Elastic Defend to collect events. +- If the selected Data View contains events that match the query in https://github.com/elastic/integrations/blob/main/packages/lmd/kibana/ml_module/lmd-ml.json configuration file, you will see a card for Lateral Movement Detection under "Use preconfigured jobs". +- Keep the default settings and click "Create jobs" to start the anomaly detection jobs and datafeeds. + +---------------------------------- + *Framework*: MITRE ATT&CK^TM^ * Tactic: diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-remote-file-extension.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-remote-file-extension.asciidoc index 317abb729c..c1e9dd1fe4 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-remote-file-extension.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-remote-file-extension.asciidoc @@ -40,6 +40,36 @@ An anomaly detection job has detected a remote file transfer with a rare extensi *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- +The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration. + +### Lateral Movement Detection Setup +The Lateral Movement Detection integration detects lateral movement activity by identifying abnormalities in file and Windows RDP events. Anomalies are detected using Elastic's Anomaly Detection feature. + +#### Prerequisite Requirements: +- Fleet is required for Lateral Movement Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html. +- File events collected by the https://docs.elastic.co/en/integrations/endpoint integration. +- To install Elastic Defend, refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html. + +#### The following steps should be executed to install assets associated with the Lateral Movement Detection integration: +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Lateral Movement Detection and select the integration to see more details about it. +- Under Settings, click Install Lateral Movement Detection assets and follow the prompts to install the assets. + +#### Anomaly Detection Setup +Before you can enable rules for Lateral Movement Detection, you'll need to enable the corresponding Anomaly Detection jobs. +- Go to the Kibana homepage. Under Analytics, click Machine Learning. +- Under Anomaly Detection, click Jobs, and then click "Create job". Select the Data View containing your file events. For example, this would be `logs-endpoint.events.*` if you used Elastic Defend to collect events. +- If the selected Data View contains events that match the query in https://github.com/elastic/integrations/blob/main/packages/lmd/kibana/ml_module/lmd-ml.json configuration file, you will see a card for Lateral Movement Detection under "Use preconfigured jobs". +- Keep the default settings and click "Create jobs" to start the anomaly detection jobs and datafeeds. + +---------------------------------- + *Framework*: MITRE ATT&CK^TM^ * Tactic: diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-remote-file-size.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-remote-file-size.asciidoc index 4376fef532..3ce2144495 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-remote-file-size.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-remote-file-size.asciidoc @@ -40,6 +40,36 @@ A machine learning job has detected an unusually high file size shared by a remo *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- +The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration. + +### Lateral Movement Detection Setup +The Lateral Movement Detection integration detects lateral movement activity by identifying abnormalities in file and Windows RDP events. Anomalies are detected using Elastic's Anomaly Detection feature. + +#### Prerequisite Requirements: +- Fleet is required for Lateral Movement Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html. +- File events collected by the https://docs.elastic.co/en/integrations/endpoint integration. +- To install Elastic Defend, refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html. + +#### The following steps should be executed to install assets associated with the Lateral Movement Detection integration: +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Lateral Movement Detection and select the integration to see more details about it. +- Under Settings, click Install Lateral Movement Detection assets and follow the prompts to install the assets. + +#### Anomaly Detection Setup +Before you can enable rules for Lateral Movement Detection, you'll need to enable the corresponding Anomaly Detection jobs. +- Go to the Kibana homepage. Under Analytics, click Machine Learning. +- Under Anomaly Detection, click Jobs, and then click "Create job". Select the Data View containing your file events. For example, this would be `logs-endpoint.events.*` if you used Elastic Defend to collect events. +- If the selected Data View contains events that match the query in https://github.com/elastic/integrations/blob/main/packages/lmd/kibana/ml_module/lmd-ml.json configuration file, you will see a card for Lateral Movement Detection under "Use preconfigured jobs". +- Keep the default settings and click "Create jobs" to start the anomaly detection jobs and datafeeds. + +---------------------------------- + *Framework*: MITRE ATT&CK^TM^ * Tactic: diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-service-host-child-process-childless-service.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-service-host-child-process-childless-service.asciidoc index 0202f75f46..bc1771c92b 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-service-host-child-process-childless-service.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-service-host-child-process-childless-service.asciidoc @@ -43,6 +43,20 @@ Identifies unusual child processes of Service Host (svchost.exe) that traditiona *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-time-or-day-for-an-rdp-session.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-time-or-day-for-an-rdp-session.asciidoc index 1baa1bba8b..7d7d4a14ca 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-time-or-day-for-an-rdp-session.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-time-or-day-for-an-rdp-session.asciidoc @@ -40,6 +40,37 @@ A machine learning job has detected an RDP session started at an usual time or w *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- +The rule requires the Lateral Movement Detection integration assets to be installed, as well as file and Windows RDP process events collected by the Elastic Defend integration. + +### Lateral Movement Detection Setup +The Lateral Movement Detection integration detects lateral movement activity by identifying abnormalities in file and Windows RDP events. Anomalies are detected using Elastic's Anomaly Detection feature. + +#### Prerequisite Requirements: +- Fleet is required for Lateral Movement Detection. +- To configure Fleet Server refer to the https://www.elastic.co/guide/en/fleet/current/fleet-server.html. +- Windows RDP process events collected by the https://docs.elastic.co/en/integrations/endpoint integration. +- To install Elastic Defend, refer to the https://www.elastic.co/guide/en/security/current/install-endpoint.html. + +#### The following steps should be executed to install assets associated with the Lateral Movement Detection integration: +- Go to the Kibana homepage. Under Management, click Integrations. +- In the query bar, search for Lateral Movement Detection and select the integration to see more details about it. +- Under Settings, click Install Lateral Movement Detection assets and follow the prompts to install the assets. + +#### Anomaly Detection Setup +Before you can enable rules for Lateral Movement Detection, you'll need to enable the corresponding Anomaly Detection jobs. +- Before enabling the Anomaly Detection jobs, confirm that the Pivot Transform asset is installed and actively gathering data in the destination index `ml-rdp-lmd`. +- Go to the Kibana homepage. Under Analytics, click Machine Learning. +- Under Anomaly Detection, click Jobs, and then click "Create job". Select the Data View containing your transformed RDP process data i.e.`ml-rdp-lmd`. +- If the selected Data View contains events that match the query in https://github.com/elastic/integrations/blob/main/packages/lmd/kibana/ml_module/lmd-ml.json configuration file, you will see a card for Lateral Movement Detection under "Use preconfigured jobs". +- Keep the default settings and click "Create jobs" to start the anomaly detection jobs and datafeeds. + +---------------------------------- + *Framework*: MITRE ATT&CK^TM^ * Tactic: diff --git a/docs/detections/prebuilt-rules/rule-details/unusual-user-privilege-enumeration-via-id.asciidoc b/docs/detections/prebuilt-rules/rule-details/unusual-user-privilege-enumeration-via-id.asciidoc index 0346961b78..babe0e11ea 100644 --- a/docs/detections/prebuilt-rules/rule-details/unusual-user-privilege-enumeration-via-id.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/unusual-user-privilege-enumeration-via-id.asciidoc @@ -38,6 +38,38 @@ This rule monitors for a sequence of 20 "id" command executions within 1 second *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/user-account-creation.asciidoc b/docs/detections/prebuilt-rules/rule-details/user-account-creation.asciidoc index 2b13977ff7..96f53da724 100644 --- a/docs/detections/prebuilt-rules/rule-details/user-account-creation.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/user-account-creation.asciidoc @@ -82,6 +82,20 @@ This rule identifies the usage of `net.exe` to create new accounts. - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/user-account-exposed-to-kerberoasting.asciidoc b/docs/detections/prebuilt-rules/rule-details/user-account-exposed-to-kerberoasting.asciidoc index 5bfe95e8be..bb62683374 100644 --- a/docs/detections/prebuilt-rules/rule-details/user-account-exposed-to-kerberoasting.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/user-account-exposed-to-kerberoasting.asciidoc @@ -64,7 +64,7 @@ By default, only computer accounts have SPNs, which creates no significant risk, A user account with an SPN assigned is considered a service account, and is accessible to the entire domain. If any user in the directory requests a ticket-granting service (TGS), the domain controller will encrypt it with the secret key of the account executing the service. An attacker can potentially perform a Kerberoasting attack with this information, as the human-defined password is likely to be less complex. -For scenarios where SPNs cannot be avoided on user accounts, Microsoft provides the Group Managed Service Accounts (gMSA) feature, which ensures that account passwords are robust and changed regularly and automatically. More information can be found [here](https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview). +For scenarios where SPNs cannot be avoided on user accounts, Microsoft provides the Group Managed Service Accounts (gMSA) feature, which ensures that account passwords are robust and changed regularly and automatically. More information can be found https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview. Attackers can also perform "Targeted Kerberoasting", which consists of adding fake SPNs to user accounts that they have write privileges to, making them potentially vulnerable to Kerberoasting. @@ -89,6 +89,35 @@ Attackers can also perform "Targeted Kerberoasting", which consists of adding fa - 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 + + +[source, markdown] +---------------------------------- + +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 User objects, so set up an AuditRule using https://github.com/OTRF/Set-AuditRule. +As this specifies the servicePrincipalName Attribute GUID, it is expected to be low noise. + +``` +Set-AuditRule -AdObjectPath 'AD:\CN=Users,DC=Domain,DC=com' -WellKnownSidType WorldSid -Rights WriteProperty -InheritanceFlags Children -AttributeGUID f3a64788-5306-11d1-a9c5-0000f80367c1 -AuditFlags Success +``` + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/user-added-as-owner-for-azure-application.asciidoc b/docs/detections/prebuilt-rules/rule-details/user-added-as-owner-for-azure-application.asciidoc index f35f51192a..38dd71b17b 100644 --- a/docs/detections/prebuilt-rules/rule-details/user-added-as-owner-for-azure-application.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/user-added-as-owner-for-azure-application.asciidoc @@ -46,6 +46,14 @@ Identifies when a user is added as an owner for an Azure application. An adversa ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/user-added-as-owner-for-azure-service-principal.asciidoc b/docs/detections/prebuilt-rules/rule-details/user-added-as-owner-for-azure-service-principal.asciidoc index ea60b5220a..1eeacb0ab2 100644 --- a/docs/detections/prebuilt-rules/rule-details/user-added-as-owner-for-azure-service-principal.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/user-added-as-owner-for-azure-service-principal.asciidoc @@ -48,6 +48,14 @@ Identifies when a user is added as an owner for an Azure service principal. The ---------------------------------- +==== Setup + + +[source, markdown] +---------------------------------- +The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/user-added-to-privileged-group.asciidoc b/docs/detections/prebuilt-rules/rule-details/user-added-to-privileged-group.asciidoc index b4b43d2f88..7ffa4f54c3 100644 --- a/docs/detections/prebuilt-rules/rule-details/user-added-to-privileged-group.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/user-added-to-privileged-group.asciidoc @@ -80,6 +80,20 @@ This rule monitors events related to a user being added to a privileged group. - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/virtual-machine-fingerprinting-via-grep.asciidoc b/docs/detections/prebuilt-rules/rule-details/virtual-machine-fingerprinting-via-grep.asciidoc index a0da3d4bd8..a0402e964d 100644 --- a/docs/detections/prebuilt-rules/rule-details/virtual-machine-fingerprinting-via-grep.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/virtual-machine-fingerprinting-via-grep.asciidoc @@ -42,6 +42,20 @@ An adversary may attempt to get detailed information about the operating system *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/virtual-machine-fingerprinting.asciidoc b/docs/detections/prebuilt-rules/rule-details/virtual-machine-fingerprinting.asciidoc index 65561e1817..98275b184d 100644 --- a/docs/detections/prebuilt-rules/rule-details/virtual-machine-fingerprinting.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/virtual-machine-fingerprinting.asciidoc @@ -41,6 +41,50 @@ An adversary may attempt to get detailed information about the operating system *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +This rule requires data coming in from one of the following integrations: +- Elastic Defend +- Auditbeat + +### 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. + +#### 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. +- 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. +- 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. + +### Auditbeat Setup +Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. + +#### The following steps should be executed in order to add the Auditbeat on a Linux System: +- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages. +- To install the APT and YUM repositories follow the setup instructions in this https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html. +- To run Auditbeat on Docker follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html. +- To run Auditbeat on Kubernetes follow the setup instructions in the https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html. +- For complete “Setup and Run Auditbeat” information refer to the https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/virtual-private-network-connection-attempt.asciidoc b/docs/detections/prebuilt-rules/rule-details/virtual-private-network-connection-attempt.asciidoc index 76924a3398..f3441ebeeb 100644 --- a/docs/detections/prebuilt-rules/rule-details/virtual-private-network-connection-attempt.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/virtual-private-network-connection-attempt.asciidoc @@ -42,6 +42,38 @@ Identifies the execution of macOS built-in commands to connect to an existing Vi *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### The following steps should be executed in order to add the Elastic Defend integration on a macOS 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, for MacOS it is recommended to select "Traditional Endpoints". +- 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/volume-shadow-copy-deleted-or-resized-via-vssadmin.asciidoc b/docs/detections/prebuilt-rules/rule-details/volume-shadow-copy-deleted-or-resized-via-vssadmin.asciidoc index 25c69e075f..329071fd33 100644 --- a/docs/detections/prebuilt-rules/rule-details/volume-shadow-copy-deleted-or-resized-via-vssadmin.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/volume-shadow-copy-deleted-or-resized-via-vssadmin.asciidoc @@ -108,6 +108,20 @@ This rule monitors the execution of Vssadmin.exe to either delete or resize shad +---------------------------------- + +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/volume-shadow-copy-deletion-via-powershell.asciidoc b/docs/detections/prebuilt-rules/rule-details/volume-shadow-copy-deletion-via-powershell.asciidoc index 69614bb0c0..086c6f1107 100644 --- a/docs/detections/prebuilt-rules/rule-details/volume-shadow-copy-deletion-via-powershell.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/volume-shadow-copy-deletion-via-powershell.asciidoc @@ -113,6 +113,20 @@ This rule monitors the execution of PowerShell cmdlets to interact with the Win3 +---------------------------------- + +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/volume-shadow-copy-deletion-via-wmic.asciidoc b/docs/detections/prebuilt-rules/rule-details/volume-shadow-copy-deletion-via-wmic.asciidoc index faaa8003a8..f02ab915f9 100644 --- a/docs/detections/prebuilt-rules/rule-details/volume-shadow-copy-deletion-via-wmic.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/volume-shadow-copy-deletion-via-wmic.asciidoc @@ -108,6 +108,20 @@ This rule monitors the execution of `wmic.exe` to interact with VSS via the `sha +---------------------------------- + +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/web-shell-detection-script-process-child-of-common-web-processes.asciidoc b/docs/detections/prebuilt-rules/rule-details/web-shell-detection-script-process-child-of-common-web-processes.asciidoc index 27456eba9a..830632dbb1 100644 --- a/docs/detections/prebuilt-rules/rule-details/web-shell-detection-script-process-child-of-common-web-processes.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/web-shell-detection-script-process-child-of-common-web-processes.asciidoc @@ -99,6 +99,20 @@ This rule detects a web server process spawning script and command-line interfac - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/webproxy-settings-modification.asciidoc b/docs/detections/prebuilt-rules/rule-details/webproxy-settings-modification.asciidoc index d615bf3239..aeb00f3819 100644 --- a/docs/detections/prebuilt-rules/rule-details/webproxy-settings-modification.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/webproxy-settings-modification.asciidoc @@ -41,6 +41,38 @@ Identifies the use of the built-in networksetup command to configure webproxy se *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +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. + +#### The following steps should be executed in order to add the Elastic Defend integration on a macOS 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, for MacOS it is recommended to select "Traditional Endpoints". +- 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. +- 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. +- 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. + + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/webserver-access-logs-deleted.asciidoc b/docs/detections/prebuilt-rules/rule-details/webserver-access-logs-deleted.asciidoc index b76f9a5f78..3e517f377a 100644 --- a/docs/detections/prebuilt-rules/rule-details/webserver-access-logs-deleted.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/webserver-access-logs-deleted.asciidoc @@ -43,6 +43,20 @@ Identifies the deletion of WebServer access logs. This may indicate an attempt t *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/whoami-process-activity.asciidoc b/docs/detections/prebuilt-rules/rule-details/whoami-process-activity.asciidoc index f6f9250795..0935cf8ddf 100644 --- a/docs/detections/prebuilt-rules/rule-details/whoami-process-activity.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/whoami-process-activity.asciidoc @@ -82,6 +82,20 @@ This rule looks for the execution of the `whoami` utility. Attackers commonly us - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/windows-defender-disabled-via-registry-modification.asciidoc b/docs/detections/prebuilt-rules/rule-details/windows-defender-disabled-via-registry-modification.asciidoc index c66eb84eab..478453d7ce 100644 --- a/docs/detections/prebuilt-rules/rule-details/windows-defender-disabled-via-registry-modification.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/windows-defender-disabled-via-registry-modification.asciidoc @@ -86,6 +86,20 @@ This rule monitors the registry for configurations that disable Windows Defender - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/windows-defender-exclusions-added-via-powershell.asciidoc b/docs/detections/prebuilt-rules/rule-details/windows-defender-exclusions-added-via-powershell.asciidoc index 06ce265324..ecaa9f06af 100644 --- a/docs/detections/prebuilt-rules/rule-details/windows-defender-exclusions-added-via-powershell.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/windows-defender-exclusions-added-via-powershell.asciidoc @@ -55,7 +55,7 @@ Identifies modifications to the Windows Defender configuration settings using Po ### Investigating Windows Defender Exclusions Added via PowerShell -Microsoft Windows Defender is an antivirus product built into Microsoft Windows. Since this software product is used to prevent and stop malware, it's important to monitor what specific exclusions are made to the product's configuration settings. These can often be signs of an adversary or malware trying to bypass Windows Defender's capabilities. One of the more notable [examples](https://www.cyberbit.com/blog/endpoint-security/latest-trickbot-variant-has-new-tricks-up-its-sleeve/) was observed in 2018 where Trickbot incorporated mechanisms to disable Windows Defender to avoid detection. +Microsoft Windows Defender is an antivirus product built into Microsoft Windows. Since this software product is used to prevent and stop malware, it's important to monitor what specific exclusions are made to the product's configuration settings. These can often be signs of an adversary or malware trying to bypass Windows Defender's capabilities. One of the more notable https://www.cyberbit.com/blog/endpoint-security/latest-trickbot-variant-has-new-tricks-up-its-sleeve/ was observed in 2018 where Trickbot incorporated mechanisms to disable Windows Defender to avoid detection. #### Possible investigation steps @@ -99,6 +99,20 @@ Microsoft Windows Defender is an antivirus product built into Microsoft Windows. - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/windows-firewall-disabled-via-powershell.asciidoc b/docs/detections/prebuilt-rules/rule-details/windows-firewall-disabled-via-powershell.asciidoc index 69befddffc..92675a8430 100644 --- a/docs/detections/prebuilt-rules/rule-details/windows-firewall-disabled-via-powershell.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/windows-firewall-disabled-via-powershell.asciidoc @@ -88,6 +88,20 @@ This rule identifies patterns related to disabling the Windows firewall or its r - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/windows-network-enumeration.asciidoc b/docs/detections/prebuilt-rules/rule-details/windows-network-enumeration.asciidoc index 63409e1e1f..37d5e7a0f5 100644 --- a/docs/detections/prebuilt-rules/rule-details/windows-network-enumeration.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/windows-network-enumeration.asciidoc @@ -79,6 +79,21 @@ This rule looks for the execution of the `net` utility to enumerate servers in t - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/windows-script-executing-powershell.asciidoc b/docs/detections/prebuilt-rules/rule-details/windows-script-executing-powershell.asciidoc index 48f25e611f..af2d894a03 100644 --- a/docs/detections/prebuilt-rules/rule-details/windows-script-executing-powershell.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/windows-script-executing-powershell.asciidoc @@ -100,6 +100,20 @@ This rule looks for the spawn of the `powershell.exe` process with `cscript.exe` - 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 + + +[source, markdown] +---------------------------------- + +If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, +events will not define `event.ingested` and default fallback for EQL rules was not added until version 8.2. +Hence for this rule to work effectively, users will need to add a custom ingest pipeline to populate +`event.ingested` to @timestamp. +For more details on adding a custom ingest pipeline refer - https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html + ---------------------------------- ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/windows-service-installed-via-an-unusual-client.asciidoc b/docs/detections/prebuilt-rules/rule-details/windows-service-installed-via-an-unusual-client.asciidoc index 207dd9e704..b9206bb025 100644 --- a/docs/detections/prebuilt-rules/rule-details/windows-service-installed-via-an-unusual-client.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/windows-service-installed-via-an-unusual-client.asciidoc @@ -43,6 +43,28 @@ Identifies the creation of a Windows service by an unusual client process. Servi *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +The 'Audit Security System Extension' logging policy must be configured for (Success) +Steps to implement the logging policy with with Advanced Audit Configuration: + +``` +Computer Configuration > +Policies > +Windows Settings > +Security Settings > +Advanced Audit Policies Configuration > +Audit Policies > +System > +Audit Security System Extension (Success) +``` + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/wireless-credential-dumping-using-netsh-command.asciidoc b/docs/detections/prebuilt-rules/rule-details/wireless-credential-dumping-using-netsh-command.asciidoc index accf8c934c..0318cfef1b 100644 --- a/docs/detections/prebuilt-rules/rule-details/wireless-credential-dumping-using-netsh-command.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/wireless-credential-dumping-using-netsh-command.asciidoc @@ -62,7 +62,7 @@ Netsh is a Windows command line tool used for network configuration and troubles This rule looks for patterns used to dump credentials from wireless network profiles using Netsh, which can enable attackers to bring their own devices to the network. > **Note**: -> This investigation guide uses the {security-guide}/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. +> This investigation guide uses the https://www.elastic.co/guide/en/security/master/invest-guide-run-osquery.html introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide. #### Possible investigation steps diff --git a/docs/detections/prebuilt-rules/rule-details/writedac-access-on-active-directory-object.asciidoc b/docs/detections/prebuilt-rules/rule-details/writedac-access-on-active-directory-object.asciidoc index bed2b3c50f..aa5c63a559 100644 --- a/docs/detections/prebuilt-rules/rule-details/writedac-access-on-active-directory-object.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/writedac-access-on-active-directory-object.asciidoc @@ -44,6 +44,27 @@ Identifies the access on an object with WRITEDAC permissions. With the WRITEDAC *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- +The 'Audit Directory Service Access' 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 Access (Success,Failure) +``` + +---------------------------------- + ==== Rule query diff --git a/docs/detections/prebuilt-rules/rule-details/zoom-meeting-with-no-passcode.asciidoc b/docs/detections/prebuilt-rules/rule-details/zoom-meeting-with-no-passcode.asciidoc index 193bf1a95f..34f752e5df 100644 --- a/docs/detections/prebuilt-rules/rule-details/zoom-meeting-with-no-passcode.asciidoc +++ b/docs/detections/prebuilt-rules/rule-details/zoom-meeting-with-no-passcode.asciidoc @@ -39,6 +39,15 @@ This rule identifies Zoom meetings that are created without a passcode. Meetings *Rule license*: Elastic License v2 +==== Setup + + +[source, markdown] +---------------------------------- + +The Zoom Filebeat module or similarly structured data is required to be compatible with this rule. +---------------------------------- + ==== Rule query diff --git a/docs/index.asciidoc b/docs/index.asciidoc index f0bd1301bc..17f29f31b7 100644 --- a/docs/index.asciidoc +++ b/docs/index.asciidoc @@ -93,3 +93,5 @@ include::detections/prebuilt-rules/downloadable-packages/8-12-2/prebuilt-rules-8 include::detections/prebuilt-rules/downloadable-packages/8-12-3/prebuilt-rules-8-12-3-appendix.asciidoc[] include::detections/prebuilt-rules/downloadable-packages/8-12-4/prebuilt-rules-8-12-4-appendix.asciidoc[] + +include::detections/prebuilt-rules/downloadable-packages/8-12-4/prebuilt-rules-8-12-4-appendix.asciidoc[]