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

nldcsc_elastic_rules/rules/linux/credential_access_potential_successful_linux_ssh_bruteforce.toml

@@ -0,0 +1,117 @@
+[metadata]
+creation_date = "2022/09/14"
+integration = ["system"]
+maturity = "production"
+updated_date = "2025/01/15"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies multiple SSH login failures followed by a successful one from the same source address. Adversaries can
+attempt to login into multiple users with a common or known password to gain access to accounts.
+"""
+from = "now-9m"
+index = ["auditbeat-*", "filebeat-*", "logs-system.auth-*"]
+language = "eql"
+license = "Elastic License v2"
+name = "Potential Successful SSH Brute Force Attack"
+note = """## Triage and analysis
+
+### Investigating Potential Successful SSH Brute Force Attack
+
+The rule identifies consecutive SSH login failures followed by a successful login from the same source IP address to the same target host indicating a successful attempt of brute force password guessing.
+
+#### Possible investigation steps
+
+- Investigate the login failure user name(s).
+- Investigate the source IP address of the failed ssh login attempt(s).
+- Investigate other alerts associated with the user/host during the past 48 hours.
+- Identify the source and the target computer and their roles in the IT environment.
+
+### False positive analysis
+
+- Authentication misconfiguration or obsolete credentials.
+- Service account password expired.
+- Infrastructure or availability issue.
+
+### Response and remediation
+
+- Initiate the incident response process based on the outcome of the triage.
+- Ensure active session(s) on the host(s) are terminated as the attacker could have gained initial access to the system(s).
+- Isolate the involved hosts to prevent further post-compromise behavior.
+- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.
+- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.
+- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
+- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
+"""
+risk_score = 73
+rule_id = "8cb84371-d053-4f4f-bce0-c74990e28f28"
+setup = """## Setup
+
+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 [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html).
+- To run Auditbeat on Docker follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html).
+- To run Auditbeat on Kubernetes follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html).
+- For complete “Setup and Run Auditbeat” information refer to the [helper guide](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 [helper guide](https://www.elastic.co/guide/en/beats/filebeat/current/setup-repositories.html).
+- To run Filebeat on Docker follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/filebeat/current/running-on-docker.html).
+- To run Filebeat on Kubernetes follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/filebeat/current/running-on-kubernetes.html).
+- For quick start information for Filebeat refer to the [helper guide](https://www.elastic.co/guide/en/beats/filebeat/8.11/filebeat-installation-configuration.html).
+- For complete “Setup and Run Filebeat” information refer to the [helper guide](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 [helper guide](https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-system.html).
+"""
+severity = "high"
+tags = ["Domain: Endpoint", "OS: Linux", "Use Case: Threat Detection", "Tactic: Credential Access", "Resources: Investigation Guide"]
+type = "eql"
+
+query = '''
+sequence by host.id, source.ip, user.name with maxspan=15s
+  [authentication where host.os.type == "linux" and event.action  in ("ssh_login", "user_login") and
+   event.outcome == "failure" and source.ip != null and source.ip != "0.0.0.0" and source.ip != "::" ] with runs=10
+
+  [authentication where host.os.type == "linux" and event.action  in ("ssh_login", "user_login") and
+   event.outcome == "success" and source.ip != null and source.ip != "0.0.0.0" and source.ip != "::" ]
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1110"
+name = "Brute Force"
+reference = "https://attack.mitre.org/techniques/T1110/"
+[[rule.threat.technique.subtechnique]]
+id = "T1110.001"
+name = "Password Guessing"
+reference = "https://attack.mitre.org/techniques/T1110/001/"
+
+[[rule.threat.technique.subtechnique]]
+id = "T1110.003"
+name = "Password Spraying"
+reference = "https://attack.mitre.org/techniques/T1110/003/"
+
+
+
+[rule.threat.tactic]
+id = "TA0006"
+name = "Credential Access"
+reference = "https://attack.mitre.org/tactics/TA0006/"
+

nldcsc_elastic_rules/rules/linux/credential_access_proc_credential_dumping.toml

@@ -0,0 +1,132 @@
+[metadata]
+creation_date = "2023/04/26"
+integration = ["endpoint", "sentinel_one_cloud_funnel"]
+maturity = "production"
+updated_date = "2025/03/20"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies the execution of the mimipenguin exploit script which is linux adaptation of Windows tool mimikatz.
+Mimipenguin exploit script is used to dump clear text passwords from a currently logged-in user. The tool exploits a
+known vulnerability CVE-2018-20781. Malicious actors can exploit the cleartext credentials in memory by dumping the
+process and extracting lines that have a high probability of containing cleartext passwords.
+"""
+from = "now-9m"
+index = ["endgame-*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"]
+language = "eql"
+license = "Elastic License v2"
+name = "Potential Linux Credential Dumping via Proc Filesystem"
+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 Potential Linux Credential Dumping via Proc Filesystem
+
+The /proc filesystem in Linux provides a window into the system's processes, offering details like memory usage and command-line arguments. Adversaries exploit this by using tools like mimipenguin to extract plaintext credentials from memory, leveraging vulnerabilities such as CVE-2018-20781. The detection rule identifies suspicious sequences involving the 'ps' and 'strings' commands, which are indicative of attempts to access and parse sensitive data from the /proc filesystem.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific host.id where the suspicious activity was detected, focusing on the processes involved.
+- Examine the process execution history on the affected host to confirm the presence of the 'ps' and 'strings' commands executed in sequence, as indicated by the query.
+- Investigate the command-line arguments used with the 'ps' and 'strings' commands to determine if they match the suspicious patterns specified in the query, such as '-eo pid command' and '/tmp/*'.
+- Check for any recent modifications or suspicious files in the /tmp directory on the affected host, as this is a common location for temporary files used in attacks.
+- Analyze the system logs and any available network traffic data to identify potential lateral movement or data exfiltration attempts following the credential dumping activity.
+- Assess the system for any signs of compromise or additional malicious activity, such as unauthorized user accounts or unexpected network connections.
+- Consider isolating the affected host from the network to prevent further credential exposure and initiate a comprehensive forensic analysis to understand the full scope of the incident.
+
+### False positive analysis
+
+- System administrators or monitoring tools may use the 'ps' and 'strings' commands for legitimate system diagnostics and performance monitoring. To mitigate this, create exceptions for known administrative scripts or tools that regularly execute these commands.
+- Automated scripts for system health checks might trigger the rule if they use 'ps' and 'strings' to gather process information. Identify and whitelist these scripts by their specific command patterns or execution paths.
+- Security tools that perform regular scans or audits might mimic the behavior detected by the rule. Review and exclude these tools by their process names or execution context to prevent false alerts.
+- Developers or testers running debugging sessions may inadvertently trigger the rule when analyzing process memory. Establish a process to temporarily disable the rule or exclude specific user accounts during known testing periods.
+- Custom monitoring solutions that log process details for analysis could match the rule's criteria. Document and exclude these solutions by their unique execution characteristics or host identifiers.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further credential exposure and potential lateral movement by the adversary.
+- Terminate any suspicious processes identified by the detection rule, specifically those involving the 'ps' and 'strings' commands with the specified arguments.
+- Conduct a thorough review of the affected system's process memory and logs to identify any additional unauthorized access or data exfiltration attempts.
+- Change passwords for all user accounts on the affected system, prioritizing those with elevated privileges, to mitigate the risk of credential misuse.
+- Apply patches and updates to address CVE-2018-20781 and any other known vulnerabilities on the affected system to prevent future exploitation.
+- Enhance monitoring and logging on the affected host and similar systems to detect any recurrence of the exploit or similar suspicious activities.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on the broader network."""
+references = [
+    "https://github.com/huntergregal/mimipenguin",
+    "https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20781",
+]
+risk_score = 47
+rule_id = "ef100a2e-ecd4-4f72-9d1e-2f779ff3c311"
+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: Credential Access",
+    "Use Case: Vulnerability",
+    "Data Source: Elastic Defend",
+    "Data Source: SentinelOne",
+    "Data Source: Elastic Endgame",
+    "Resources: Investigation Guide",
+]
+type = "eql"
+
+query = '''
+sequence by host.id, process.parent.name with maxspan=1m
+  [process where host.os.type == "linux" and process.name == "ps" and event.action in ("exec", "start", "exec_event")
+   and process.args in ("-eo", "pid", "command")]
+  [process where host.os.type == "linux" and process.name == "strings" and event.action in ("exec", "start", "exec_event")
+   and process.args : "/tmp/*"]
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1003"
+name = "OS Credential Dumping"
+reference = "https://attack.mitre.org/techniques/T1003/"
+[[rule.threat.technique.subtechnique]]
+id = "T1003.007"
+name = "Proc Filesystem"
+reference = "https://attack.mitre.org/techniques/T1003/007/"
+
+
+[[rule.threat.technique]]
+id = "T1212"
+name = "Exploitation for Credential Access"
+reference = "https://attack.mitre.org/techniques/T1212/"
+
+
+[rule.threat.tactic]
+id = "TA0006"
+name = "Credential Access"
+reference = "https://attack.mitre.org/tactics/TA0006/"
+

nldcsc_elastic_rules/rules/linux/credential_access_sensitive_keys_or_passwords_search_inside_container.toml

@@ -0,0 +1,119 @@
+[metadata]
+creation_date = "2025/03/12"
+integration = ["endpoint"]
+maturity = "production"
+updated_date = "2025/03/12"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule detects the use of system search utilities like grep and find to search for private SSH keys or passwords
+inside a container. Unauthorized access to these sensitive files could lead to further compromise of the container
+environment or facilitate a container breakout to the underlying host machine.
+"""
+from = "now-9m"
+index = ["logs-endpoint.events.process*"]
+language = "eql"
+license = "Elastic License v2"
+name = "Sensitive Keys Or Passwords Searched For Inside A Container"
+references = ["https://sysdig.com/blog/cve-2021-25741-kubelet-falco/"]
+risk_score = 47
+rule_id = "23cd4ba2-344e-41bf-bcda-655bea43fdbc"
+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: Container",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Credential Access",
+    "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.entry_leader.entry_meta.type == "container" and
+process.name in ("grep", "egrep", "fgrep", "find", "locate", "mlocate") and
+process.command_line like~ (
+  "*BEGIN PRIVATE*", "*BEGIN OPENSSH PRIVATE*", "*BEGIN RSA PRIVATE*", "*BEGIN DSA PRIVATE*", "*BEGIN EC PRIVATE*",
+  "*pass*", "*ssh*", "*user*", "*id_rsa*", "*id_dsa*"
+)
+'''
+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 Sensitive Keys Or Passwords Searched For Inside A Container
+
+Containers encapsulate applications, providing isolated environments. Adversaries may exploit search utilities like grep or find to locate sensitive credentials within containers, potentially leading to unauthorized access or container escape. The detection rule identifies suspicious searches for private keys or passwords, flagging potential credential access attempts by monitoring process activities and arguments.
+
+### Possible investigation steps
+
+- Examine the process.name and process.args fields to determine the exact command executed and assess whether it aligns with typical usage patterns or indicates malicious intent.
+- Check the user context under which the process was executed to understand if the activity was performed by a legitimate user or an unauthorized entity.
+- Investigate the container's recent activity logs to identify any other suspicious behavior or anomalies that might correlate with the search for sensitive keys or passwords.
+- Assess the potential impact by determining if any sensitive files, such as private keys or password files, were accessed or exfiltrated following the search activity.
+- If possible, correlate the event with network logs to identify any outbound connections that might suggest data exfiltration attempts.
+
+### False positive analysis
+
+- Routine administrative tasks may trigger the rule when system administrators use grep or find to audit or manage SSH keys and passwords within containers. To mitigate this, create exceptions for known administrative scripts or processes that regularly perform these tasks.
+- Automated backup or configuration management tools might search for sensitive files as part of their normal operation. Identify these tools and exclude their process IDs or specific command patterns from triggering the rule.
+- Security scanning tools that check for the presence of sensitive files could be flagged. Whitelist these tools by their process names or arguments to prevent false positives.
+- Developers or DevOps personnel might use search utilities during debugging or development processes. Establish a list of trusted users or roles and exclude their activities from the rule to reduce noise.
+- Continuous integration/continuous deployment (CI/CD) pipelines may include steps that search for keys or passwords for validation purposes. Exclude these pipeline processes by identifying their unique process arguments or container IDs.
+
+### Response and remediation
+
+- Immediately isolate the affected container to prevent further unauthorized access or potential container escape to the host system. This can be done by stopping the container or disconnecting it from the network.
+- Conduct a thorough review of the container's logs and process activities to identify any unauthorized access or data exfiltration attempts. Pay special attention to the processes and arguments flagged by the detection rule.
+- Rotate any potentially compromised credentials, including SSH keys and passwords, that were stored or accessed within the container. Ensure that new credentials are securely stored and managed.
+- Assess the container's configuration and access controls to identify and rectify any security misconfigurations that may have allowed the unauthorized search for sensitive information.
+- Implement additional monitoring and alerting for similar suspicious activities across other containers and the host environment to detect and respond to potential threats promptly.
+- Escalate the incident to the security operations team for further investigation and to determine if the threat has spread beyond the initial container.
+- Review and update container security policies and practices to prevent recurrence, including enforcing least privilege access and using secrets management solutions to handle sensitive information securely."""
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[[rule.threat.technique]]
+id = "T1552"
+name = "Unsecured Credentials"
+reference = "https://attack.mitre.org/techniques/T1552/"
+
+[[rule.threat.technique.subtechnique]]
+id = "T1552.001"
+name = "Credentials In Files"
+reference = "https://attack.mitre.org/techniques/T1552/001/"
+
+[rule.threat.tactic]
+id = "TA0006"
+name = "Credential Access"
+reference = "https://attack.mitre.org/tactics/TA0006/"

nldcsc_elastic_rules/rules/linux/credential_access_ssh_backdoor_log.toml

@@ -0,0 +1,174 @@
+[metadata]
+creation_date = "2020/12/21"
+integration = ["endpoint", "sentinel_one_cloud_funnel"]
+maturity = "production"
+updated_date = "2025/03/20"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies a Secure Shell (SSH) client or server process creating or writing to a known SSH backdoor log file.
+Adversaries may modify SSH related binaries for persistence or credential access via patching sensitive functions to
+enable unauthorized access or to log SSH credentials for exfiltration.
+"""
+false_positives = ["Updates to approved and trusted SSH executables can trigger this rule."]
+from = "now-9m"
+index = ["auditbeat-*", "logs-endpoint.events.file-*", "endgame-*", "logs-sentinel_one_cloud_funnel.*"]
+language = "eql"
+license = "Elastic License v2"
+name = "Potential OpenSSH Backdoor Logging Activity"
+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 Potential OpenSSH Backdoor Logging Activity
+
+OpenSSH is a widely used protocol for secure remote administration and file transfers. Adversaries may exploit OpenSSH by modifying its binaries to log credentials or maintain unauthorized access. The detection rule identifies suspicious file changes linked to SSH processes, focusing on unusual file names, extensions, and paths indicative of backdoor activity, thus helping to uncover potential security breaches.
+
+### Possible investigation steps
+
+- Review the file change event details to identify the specific file name, extension, and path involved in the alert. Pay particular attention to unusual file names or extensions and paths listed in the query, such as "/usr/lib/*.so.*" or "/private/etc/ssh/.sshd_auth".
+- Examine the process executable that triggered the alert, either "/usr/sbin/sshd" or "/usr/bin/ssh", to determine if it has been modified or replaced. Check the integrity of these binaries using hash comparisons against known good versions.
+- Investigate the user account associated with the process that made the file change. Determine if the account has a history of suspicious activity or if it has been compromised.
+- Check for any recent or unusual login attempts or sessions related to the SSH service on the host. Look for patterns that might indicate unauthorized access or credential harvesting.
+- Analyze system logs, such as auth.log or secure.log, for any anomalies or entries that coincide with the time of the file change event. This can provide additional context or evidence of malicious activity.
+- If a backdoor is suspected, consider isolating the affected system from the network to prevent further unauthorized access and begin remediation efforts, such as restoring from a clean backup or reinstalling the affected services.
+
+### False positive analysis
+
+- Routine system updates or package installations may trigger file changes in SSH-related directories. Users can create exceptions for known update processes to prevent false alerts.
+- Custom scripts or administrative tasks that modify SSH configuration files for legitimate purposes might be flagged. Users should whitelist these scripts or processes if they are verified as non-malicious.
+- Backup or synchronization tools that create temporary files with unusual extensions or names in SSH directories can cause false positives. Exclude these tools from monitoring if they are part of regular operations.
+- Development or testing environments where SSH binaries are frequently modified for testing purposes may generate alerts. Implement exclusions for these environments to reduce noise.
+- Automated configuration management tools like Ansible or Puppet that modify SSH settings as part of their operations can be excluded if they are part of authorized workflows.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any suspicious SSH processes identified in the alert to halt potential backdoor activity.
+- Conduct a thorough review of the modified files and binaries, particularly those listed in the query, to assess the extent of the compromise and identify any malicious code or unauthorized changes.
+- Restore affected files and binaries from a known good backup to ensure system integrity and remove any backdoor modifications.
+- Change all SSH credentials and keys associated with the compromised system to prevent unauthorized access using potentially logged credentials.
+- Implement additional monitoring on the affected system and network for any signs of persistence or further malicious activity, focusing on the paths and file types highlighted in the detection query.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected, ensuring a coordinated response to the threat."""
+references = [
+    "https://github.com/eset/malware-ioc/tree/master/sshdoor",
+    "https://www.welivesecurity.com/wp-content/uploads/2021/01/ESET_Kobalos.pdf",
+]
+risk_score = 21
+rule_id = "f28e2be4-6eca-4349-bdd9-381573730c22"
+setup = """## Setup
+
+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 [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).
+
+### 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 [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html).
+- To run Auditbeat on Docker follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html).
+- To run Auditbeat on Kubernetes follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html).
+- For complete “Setup and Run Auditbeat” information refer to the [helper guide](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 [guide](https://www.elastic.co/guide/en/fleet/current/data-streams-pipeline-tutorial.html).
+"""
+severity = "low"
+tags = [
+    "Domain: Endpoint",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Persistence",
+    "Tactic: Credential Access",
+    "Data Source: Elastic Endgame",
+    "Data Source: Elastic Defend",
+    "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+file where host.os.type == "linux" and event.type == "change" and process.executable : ("/usr/sbin/sshd", "/usr/bin/ssh") and
+  (
+    (file.name : (".*", "~*", "*~") and not file.name : (".cache", ".viminfo", ".bash_history", ".google_authenticator",
+      ".jelenv", ".csvignore", ".rtreport")) or
+    file.extension : ("in", "out", "ini", "h", "gz", "so", "sock", "sync", "0", "1", "2", "3", "4", "5", "6", "7", "8", "9") or
+    file.path :
+    (
+      "/private/etc/*--",
+      "/usr/share/*",
+      "/usr/include/*",
+      "/usr/local/include/*",
+      "/private/tmp/*",
+      "/private/var/tmp/*",
+      "/usr/tmp/*",
+      "/usr/share/man/*",
+      "/usr/local/share/*",
+      "/usr/lib/*.so.*",
+      "/private/etc/ssh/.sshd_auth",
+      "/usr/bin/ssd",
+      "/private/var/opt/power",
+      "/private/etc/ssh/ssh_known_hosts",
+      "/private/var/html/lol",
+      "/private/var/log/utmp",
+      "/private/var/lib",
+      "/var/run/sshd/sshd.pid",
+      "/var/run/nscd/ns.pid",
+      "/var/run/udev/ud.pid",
+      "/var/run/udevd.pid"
+    )
+  )
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1556"
+name = "Modify Authentication Process"
+reference = "https://attack.mitre.org/techniques/T1556/"
+
+
+[rule.threat.tactic]
+id = "TA0006"
+name = "Credential Access"
+reference = "https://attack.mitre.org/tactics/TA0006/"
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1554"
+name = "Compromise Host Software Binary"
+reference = "https://attack.mitre.org/techniques/T1554/"
+
+
+[rule.threat.tactic]
+id = "TA0003"
+name = "Persistence"
+reference = "https://attack.mitre.org/tactics/TA0003/"
+