nldcsc-elastic-rules 0.0.8__py3-none-any.whl

nldcsc_elastic_rules/rules/linux/persistence_unusual_sshd_child_process.toml

@@ -0,0 +1,136 @@
+[metadata]
+creation_date = "2024/12/16"
+integration = ["endpoint", "crowdstrike"]
+maturity = "production"
+updated_date = "2025/10/17"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule detects the creation of an unusual SSHD child process through the usage of the `new_terms` rule type.
+Attackers may abuse SSH to maintain persistence on a compromised system, or to establish a backdoor for remote access,
+potentially resulting in an unusual SSHD child process being created.
+"""
+from = "now-9m"
+index = ["logs-endpoint.events.process*", "logs-crowdstrike.fdr*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Unusual SSHD Child Process"
+references = ["https://hadess.io/the-art-of-linux-persistence/"]
+risk_score = 47
+rule_id = "4c3c6c47-e38f-4944-be27-5c80be973bd7"
+severity = "medium"
+tags = [
+  "Domain: Endpoint",
+  "OS: Linux",
+  "Use Case: Threat Detection",
+  "Tactic: Persistence",
+  "Data Source: Elastic Defend",
+  "Resources: Investigation Guide",
+  "Data Source: Crowdstrike",
+]
+timestamp_override = "event.ingested"
+type = "new_terms"
+query = '''
+event.category:process and host.os.type:linux and event.type:start and event.action:(exec or ProcessRollup2) and
+process.parent.name:(ssh or sshd) and process.args_count:2 and
+not (
+  process.command_line:(-bash or -zsh or -sh) or
+  process.name:(ractrans or exectask or tty or tput or ferny-askpass or id or ip)
+)
+'''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating Unusual SSHD Child Process
+
+Secure Shell (SSH) is a protocol used to securely access remote systems. Adversaries may exploit SSH to maintain persistence or create backdoors by spawning unexpected child processes. The detection rule identifies anomalies by monitoring process creation events where SSH or SSHD is the parent, focusing on atypical command-line arguments, which may indicate malicious activity.
+
+### Possible investigation steps
+
+- Review the process command line arguments for the unusual SSHD child process to identify any suspicious or unexpected commands that could indicate malicious activity.
+- Check the user account associated with the SSHD child process to determine if it is a legitimate user or if there are signs of compromise, such as unusual login times or locations.
+- Investigate the parent process (SSH or SSHD) to understand the context of the connection, including the source IP address and any associated user activity, to assess if it aligns with expected behavior.
+- Examine the process tree to identify any subsequent processes spawned by the unusual SSHD child process, which may provide further insight into the attacker's actions or objectives.
+- Correlate the event with other security logs and alerts from the same host or network segment to identify any related suspicious activities or patterns that could indicate a broader attack campaign.
+
+### False positive analysis
+
+- Legitimate administrative scripts or automation tools may trigger this rule if they execute commands with SSH or SSHD as the parent process. To handle this, identify and document these scripts, then create exceptions for their specific command-line patterns.
+- System maintenance tasks or updates that involve SSH connections might appear as unusual child processes. Regularly review and whitelist these known maintenance activities to prevent unnecessary alerts.
+- Custom user environments or shell configurations that deviate from standard shells like bash, zsh, or sh could be flagged. Analyze these configurations and exclude them if they are verified as non-threatening.
+- Monitoring tools or security solutions that interact with SSH sessions for logging or auditing purposes might generate alerts. Verify these tools' behavior and exclude their processes if they are part of legitimate monitoring activities.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
+- Terminate any suspicious SSHD child processes identified by the alert to halt potential malicious activities.
+- Conduct a thorough review of SSH configuration files and access logs to identify unauthorized changes or access patterns, and revert any unauthorized modifications.
+- Change all SSH keys and credentials associated with the compromised system to prevent further unauthorized access.
+- Implement additional monitoring on the affected system and related network segments to detect any further suspicious activities or attempts to re-establish persistence.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if other systems may be affected.
+- Review and update firewall rules and access controls to restrict SSH access to only trusted IP addresses and users, reducing the attack surface for future incidents."""
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[[rule.threat.technique]]
+id = "T1546"
+name = "Event Triggered Execution"
+reference = "https://attack.mitre.org/techniques/T1546/"
+
+[[rule.threat.technique.subtechnique]]
+id = "T1546.004"
+name = "Unix Shell Configuration Modification"
+reference = "https://attack.mitre.org/techniques/T1546/004/"
+
+[rule.threat.tactic]
+id = "TA0003"
+name = "Persistence"
+reference = "https://attack.mitre.org/tactics/TA0003/"
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[[rule.threat.technique]]
+id = "T1021"
+name = "Remote Services"
+reference = "https://attack.mitre.org/techniques/T1021/"
+
+[[rule.threat.technique.subtechnique]]
+id = "T1021.004"
+name = "SSH"
+reference = "https://attack.mitre.org/techniques/T1021/004/"
+
+[[rule.threat.technique]]
+id = "T1563"
+name = "Remote Service Session Hijacking"
+reference = "https://attack.mitre.org/techniques/T1563/"
+
+[[rule.threat.technique.subtechnique]]
+id = "T1563.001"
+name = "SSH Hijacking"
+reference = "https://attack.mitre.org/techniques/T1563/001/"
+
+[rule.threat.tactic]
+id = "TA0008"
+name = "Lateral Movement"
+reference = "https://attack.mitre.org/tactics/TA0008/"
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[rule.threat.tactic]
+id = "TA0011"
+name = "Command and Control"
+reference = "https://attack.mitre.org/tactics/TA0011/"
+
+[rule.new_terms]
+field = "new_terms_fields"
+value = ["process.executable"]
+
+[[rule.new_terms.history_window_start]]
+field = "history_window_start"
+value = "now-14d"

nldcsc_elastic_rules/rules/linux/persistence_user_credential_modification_via_echo.toml

@@ -0,0 +1,109 @@
+[metadata]
+creation_date = "2025/02/21"
+integration = ["endpoint"]
+maturity = "production"
+updated_date = "2025/04/07"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule detects Linux user account credential modification events where the echo command is
+used to directly echo a password into the passwd utility. This technique is used by malware
+to automate the process of user account credential modification on Linux systems post-infection.
+"""
+from = "now-9m"
+index = ["logs-endpoint.events.process*"]
+language = "eql"
+license = "Elastic License v2"
+name = "Linux User Account Credential Modification"
+note = """ ## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating Linux User Account Credential Modification
+
+In Linux environments, user account credentials are crucial for system access and management. Adversaries may exploit command-line utilities to modify credentials, often using scripts to automate this process post-infection. The detection rule identifies suspicious use of shell commands that echo passwords into the passwd utility, a technique indicative of unauthorized credential changes, by monitoring specific command patterns and excluding benign processes.
+
+### Possible investigation steps
+
+- Review the process command line to confirm the presence of the suspicious pattern "*echo*passwd*" and assess if it aligns with known malicious activity.
+- Identify the user account associated with the process to determine if it is a legitimate user or potentially compromised.
+- Examine the parent process details, including the command line and executable path, to understand the context of how the suspicious process was initiated.
+- Check for any recent changes to user accounts on the system, focusing on password modifications or new account creations around the time of the alert.
+- Investigate the system for any additional signs of compromise, such as unexpected network connections or other suspicious processes running concurrently.
+- Correlate the event with other security alerts or logs to identify if this activity is part of a broader attack pattern or campaign.
+
+### False positive analysis
+
+- Automated build processes may trigger this rule if they use shell scripts that include echoing passwords for testing or configuration purposes. To handle this, exclude processes with parent command lines or executables related to build tools like make.
+- System administration scripts that automate user account management might use similar command patterns. Review these scripts and exclude them by specifying their parent process or executable paths.
+- Custom user scripts for password management could inadvertently match the rule's criteria. Identify these scripts and add exceptions based on their unique command line or parent process attributes.
+- Some legitimate software installations might use echo and passwd in their setup scripts. Monitor installation logs and exclude known safe installation processes by their parent command line or executable.
+
+### Response and remediation
+
+- Immediately isolate the affected Linux system from the network to prevent further unauthorized access or lateral movement by the adversary.
+- Terminate any suspicious processes identified by the detection rule, particularly those involving the echo command being used with the passwd utility.
+- Change the passwords of any user accounts that may have been compromised, ensuring the use of strong, unique passwords.
+- Review and audit recent user account changes and access logs to identify any unauthorized modifications or access attempts.
+- Restore any affected user accounts to their previous state using backups or system snapshots, if available.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
+- Implement additional monitoring and alerting for similar command patterns to enhance detection and prevent recurrence of this threat.
+"""
+risk_score = 21
+rule_id = "79e7291f-9e3b-4a4b-9823-800daa89c8f9"
+setup = """## Setup
+This rule requires data coming in from Elastic Defend.
+### Elastic Defend Integration Setup
+Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.
+#### Prerequisite Requirements:
+- Fleet is required for Elastic Defend.
+- To configure Fleet Server refer to the [documentation](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. [Helper guide](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 [helper guide](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 [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
+"""
+severity = "low"
+tags = [
+    "Domain: Endpoint",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Persistence",
+    "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+query = '''
+process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
+process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and
+process.command_line like~ "*echo*passwd*" and
+not (
+  process.parent.command_line == "runc init" or
+  process.parent.executable in ("/usr/bin/make", "/bin/make")
+)
+'''
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[[rule.threat.technique]]
+id = "T1098"
+name = "Account Manipulation"
+reference = "https://attack.mitre.org/techniques/T1098/"
+
+[rule.threat.tactic]
+id = "TA0003"
+name = "Persistence"
+reference = "https://attack.mitre.org/tactics/TA0003/"

nldcsc_elastic_rules/rules/linux/persistence_user_or_group_creation_or_modification.toml

@@ -0,0 +1,129 @@
+[metadata]
+creation_date = "2024/06/20"
+integration = ["auditd_manager"]
+maturity = "production"
+updated_date = "2025/01/24"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule leverages the `auditd_manager` integration to detect user or group creation or modification events on Linux
+systems. Threat actors may attempt to create or modify users or groups to establish persistence on the system.
+"""
+from = "now-9m"
+index = ["auditbeat-*", "logs-auditd_manager.auditd-*"]
+language = "eql"
+license = "Elastic License v2"
+name = "User or Group Creation/Modification"
+references = ["https://www.elastic.co/security-labs/primer-on-persistence-mechanisms"]
+risk_score = 21
+rule_id = "fcf733d5-7801-4eb0-92ac-8ffacf3658f2"
+setup = """## Setup
+
+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 [helper guide](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 to trigger, the following additional audit rules are required to be added to the integration:
+```
+-w /usr/sbin/groupadd -p x -k group_modification
+-w /sbin/groupadd -p x -k group_modification
+-w /usr/sbin/groupmod -p x -k group_modification
+-w /sbin/groupmod -p x -k group_modification
+-w /usr/sbin/addgroup -p x -k group_modification
+-w /sbin/addgroup -p x -k group_modification
+-w /usr/sbin/usermod -p x -k user_modification
+-w /sbin/usermod -p x -k user_modification
+-w /usr/sbin/userdel -p x -k user_modification
+-w /sbin/userdel -p x -k user_modification
+-w /usr/sbin/useradd -p x -k user_modification
+-w /sbin/useradd -p x -k user_modification
+-w /usr/sbin/adduser -p x -k user_modification
+-w /sbin/adduser -p x -k user_modification
+```
+"""
+severity = "low"
+tags = [
+    "Domain: Endpoint",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Persistence",
+    "Data Source: Auditd Manager",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+iam where host.os.type == "linux" and event.type in ("creation", "change") and auditd.result == "success" and
+event.action in ("changed-password", "added-user-account", "added-group-account-to") and process.name != null
+'''
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating User or Group Creation/Modification
+
+In Linux environments, user and group management is crucial for access control and system administration. Adversaries may exploit this by creating or modifying accounts to maintain unauthorized access. The detection rule utilizes audit logs to monitor successful user or group changes, flagging potential persistence tactics by correlating specific actions with known threat behaviors.
+
+### Possible investigation steps
+
+- Review the audit logs to identify the specific user or group account that was created or modified, focusing on the event.action field values such as "changed-password", "added-user-account", or "added-group-account-to".
+- Check the timestamp of the event to determine when the account change occurred and correlate it with any other suspicious activities or alerts around the same time.
+- Investigate the source of the event by examining the host information, particularly the host.os.type field, to understand which system the changes were made on.
+- Identify the user or process that initiated the account change by reviewing the associated user information in the audit logs, which may provide insights into whether the action was authorized or potentially malicious.
+- Cross-reference the identified user or group changes with known threat actor behaviors or recent incidents to assess if the activity aligns with any known persistence tactics.
+
+### False positive analysis
+
+- Routine administrative tasks may trigger alerts when system administrators create or modify user or group accounts as part of regular maintenance. To manage this, consider creating exceptions for known administrative accounts or scheduled maintenance windows.
+- Automated scripts or configuration management tools that manage user accounts can generate false positives. Identify these tools and exclude their actions from triggering alerts by whitelisting their processes or user accounts.
+- System updates or software installations that require user or group modifications might be flagged. Review the context of these changes and exclude specific update processes or installation scripts from the rule.
+- Temporary user accounts created for short-term projects or testing purposes can be mistaken for unauthorized access attempts. Implement a naming convention for temporary accounts and exclude them from the rule to reduce noise.
+- Changes made by trusted third-party services or applications that integrate with the system may appear suspicious. Verify these services and add them to an exception list to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
+- Review the audit logs to identify the specific user or group accounts that were created or modified, and disable or remove any unauthorized accounts.
+- Reset passwords for any compromised or suspicious accounts to prevent further unauthorized access.
+- Conduct a thorough review of system and application logs to identify any additional unauthorized changes or suspicious activities that may have occurred.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been compromised.
+- Implement additional monitoring on the affected system and similar systems to detect any further unauthorized account activities.
+- Review and update access control policies and procedures to prevent similar incidents in the future, ensuring that only authorized personnel have the ability to create or modify user and group accounts."""
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1136"
+name = "Create Account"
+reference = "https://attack.mitre.org/techniques/T1136/"
+[[rule.threat.technique.subtechnique]]
+id = "T1136.001"
+name = "Local Account"
+reference = "https://attack.mitre.org/techniques/T1136/001/"
+
+
+
+[rule.threat.tactic]
+id = "TA0003"
+name = "Persistence"
+reference = "https://attack.mitre.org/tactics/TA0003/"
+

nldcsc_elastic_rules/rules/linux/persistence_web_server_sus_child_spawned.toml

@@ -0,0 +1,234 @@
+[metadata]
+creation_date = "2025/03/04"
+integration = ["endpoint"]
+maturity = "production"
+updated_date = "2025/09/02"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule detects unusual processes spawned from a web server parent process by identifying low frequency counts of
+process spawning activity. Unusual process spawning activity may indicate an attacker attempting to establish
+persistence, execute malicious commands, or establish command and control channels on the host system. ESQL rules have
+limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation
+of this alert.
+"""
+from = "now-61m"
+interval = "1h"
+language = "esql"
+license = "Elastic License v2"
+name = "Unusual Process Spawned from Web Server Parent"
+note = """ ## Triage and analysis
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+### Investigating Unusual Process Spawned from Web Server Parent
+
+Web servers like Apache, Nginx, and others are crucial for hosting applications and services. Adversaries exploit these servers by spawning unauthorized processes to maintain persistence or execute malicious commands. The detection rule identifies anomalies by monitoring low-frequency process spawns from web server parents, focusing on unusual user IDs, directories, and process counts, which may indicate potential threats.
+
+### Possible investigation steps
+
+- Review the process.executable and process.command_line fields to understand the nature of the process that was spawned and assess if it aligns with expected behavior for the web server environment.
+- Examine the process.working_directory to determine if the directory is a legitimate location for web server operations or if it appears suspicious, such as being outside typical web server directories.
+- Check the user.name and user.id fields to verify if the process was executed by a legitimate web server user or if it was initiated by an unexpected or unauthorized user account.
+- Investigate the process.parent.executable to confirm whether the parent process is a known and trusted web server executable or if it has been tampered with or replaced.
+- Correlate the event with other logs or alerts from the same agent.id to identify any additional suspicious activities or patterns that may indicate a broader compromise.
+- Assess the host.os.type to ensure the alert pertains to a Linux system, as specified in the query, and verify if there are any known vulnerabilities or misconfigurations on the host that could have been exploited.
+
+### False positive analysis
+
+- Processes related to legitimate web server maintenance tasks may trigger alerts. Review scheduled tasks or cron jobs that align with the alert timing and consider excluding these specific processes if they are verified as non-threatening.
+- Development environments often spawn processes that mimic attack patterns. Identify and exclude processes originating from known development directories or executed by development user accounts.
+- Automated scripts or monitoring tools running under web server user accounts can be mistaken for malicious activity. Verify these scripts and add exceptions for their specific process names or working directories.
+- Frequent updates or deployments in web applications can lead to unusual process spawns. Document these activities and exclude related processes if they consistently match the alert criteria during known update windows.
+- Custom web server modules or plugins may execute processes that appear suspicious. Validate these modules and exclude their associated processes if they are part of normal operations.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further malicious activity and potential lateral movement.
+- Terminate any suspicious processes identified by the alert that are not part of legitimate web server operations.
+- Conduct a thorough review of the process command lines and executables flagged by the alert to identify any malicious scripts or binaries. Remove or quarantine these files as necessary.
+- Check for unauthorized changes in web server configurations or files within the working directories flagged by the alert. Restore any altered files from a known good backup.
+- Review user accounts and permissions associated with the web server processes to ensure no unauthorized accounts or privilege escalations have occurred. Reset passwords and revoke unnecessary access.
+- Monitor network traffic from the affected host for any signs of command and control communication, and block any identified malicious IP addresses or domains.
+- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised.
+"""
+risk_score = 47
+rule_id = "976b2391-413f-4a94-acb4-7911f3803346"
+setup = """## Setup
+
+This rule requires data coming in from Elastic Defend.
+
+### Elastic Defend Integration Setup
+Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.
+
+#### Prerequisite Requirements:
+- Fleet is required for Elastic Defend.
+- To configure Fleet Server refer to the [documentation](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. [Helper guide](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 [helper guide](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 [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
+"""
+severity = "medium"
+tags = [
+    "Domain: Endpoint",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Persistence",
+    "Tactic: Execution",
+    "Tactic: Command and Control",
+    "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "esql"
+query = '''
+from logs-endpoint.events.process-*
+| keep
+    @timestamp,
+    host.os.type,
+    event.type,
+    event.action,
+    process.parent.name,
+    user.name,
+    user.id,
+    process.working_directory,
+    process.name,
+    process.executable,
+    process.command_line,
+    process.parent.executable,
+    agent.id,
+    host.name
+| where
+    @timestamp > now() - 1 hours and
+    host.os.type == "linux" and
+    event.type == "start" and
+    event.action == "exec" and (
+      (
+        process.parent.name in (
+            "apache", "nginx", "apache2", "httpd", "lighttpd", "caddy", "node", "mongrel_rails", "java", "gunicorn",
+            "uwsgi", "openresty", "cherokee", "h2o", "resin", "puma", "unicorn", "traefik", "tornado", "hypercorn",
+            "daphne", "twistd", "yaws", "webfsd", "httpd.worker", "flask", "rails", "mongrel"
+        ) or
+        user.name in (
+            "apache", "www-data", "httpd", "nginx", "lighttpd", "tomcat", "tomcat8", "tomcat9", "ftp", "ftpuser", "ftpd"
+        ) or
+        user.id in ("99", "33", "498", "48") or
+        process.working_directory like "/var/www/*"
+      ) or
+      (
+        (
+          process.parent.name like "php-*" or
+          process.parent.name like "python*" or
+          process.parent.name like "ruby*" or
+          process.parent.name like "perl*"
+        ) and (
+          process.working_directory like "/var/www/*" or
+          process.working_directory like "/srv/www/*" or
+          process.working_directory like "/usr/share/nginx/*"
+        )
+      )
+    ) and (
+        process.name in (
+          "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "socat", "openssl", "busybox",
+          "nc", "ncat", "netcat", "nc.openbsd", "nc.traditional", "nohup", "setsid", "mkfifo", "mknod",
+          "node", "socket"
+        ) or
+        process.name like "python*" or
+        process.name like "php*" or
+        process.name like "perl" or
+        process.name like "ruby*" or
+        process.name like "lua*" or
+        process.executable like "/tmp/*" or
+        process.executable like "/var/tmp/*" or
+        process.executable like "/dev/shm/*" or
+        process.executable like "/var/log/*" or
+        process.executable like "/sys/*" or
+        process.executable like "/media/*" or
+        process.executable like "/proc/*" or
+        process.executable like "/var/backups/*" or
+        process.executable like "/var/mail/*" or
+        process.executable like "/var/spool/*" or
+        process.executable like "/var/www/*" or
+        process.executable like "./*" or
+        process.name like ".*"
+    ) and    
+    not (
+        process.working_directory like "/home/*" or
+        process.working_directory == "/" or
+        process.working_directory like "/var/www/*.ch" or
+        process.parent.executable like "/vscode/vscode-server/*"
+    )
+| stats
+    Esql.event_count = count(),
+    Esql.agent_id_count_distinct = count_distinct(agent.id),
+    Esql.host_name_values = values(host.name),
+    Esql.agent_id_values = values(agent.id)
+  by process.executable, process.working_directory, process.parent.executable
+| where
+    Esql.agent_id_count_distinct == 1 and
+    Esql.event_count < 5
+| sort Esql.event_count asc
+| limit 100
+'''
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[[rule.threat.technique]]
+id = "T1505"
+name = "Server Software Component"
+reference = "https://attack.mitre.org/techniques/T1505/"
+
+[[rule.threat.technique.subtechnique]]
+id = "T1505.003"
+name = "Web Shell"
+reference = "https://attack.mitre.org/techniques/T1505/003/"
+
+[rule.threat.tactic]
+id = "TA0003"
+name = "Persistence"
+reference = "https://attack.mitre.org/tactics/TA0003/"
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[[rule.threat.technique]]
+id = "T1059"
+name = "Command and Scripting Interpreter"
+reference = "https://attack.mitre.org/techniques/T1059/"
+
+[[rule.threat.technique.subtechnique]]
+id = "T1059.004"
+name = "Unix Shell"
+reference = "https://attack.mitre.org/techniques/T1059/004/"
+
+[rule.threat.tactic]
+id = "TA0002"
+name = "Execution"
+reference = "https://attack.mitre.org/tactics/TA0002/"
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[[rule.threat.technique]]
+id = "T1071"
+name = "Application Layer Protocol"
+reference = "https://attack.mitre.org/techniques/T1071/"
+
+[rule.threat.tactic]
+id = "TA0011"
+name = "Command and Control"
+reference = "https://attack.mitre.org/tactics/TA0011/"