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

nldcsc_elastic_rules/rules/linux/lateral_movement_remote_file_creation_world_writeable_dir.toml

@@ -0,0 +1,141 @@
+[metadata]
+creation_date = "2025/02/20"
+integration = ["endpoint"]
+maturity = "production"
+updated_date = "2025/11/12"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule detects the creation of a file in a world-writeable directory through a service that is
+commonly used for file transfer. This behavior is often associated with lateral movement and can
+be an indicator of an attacker attempting to move laterally within a network.
+"""
+from = "now-9m"
+index = ["logs-endpoint.events.file*", "auditbeat-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Remote File Creation in World Writeable Directory"
+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 Remote File Creation in World Writeable Directory
+
+In Linux environments, world-writeable directories like `/tmp` and `/var/tmp` are used for temporary file storage, accessible by all users. Adversaries exploit these directories to deposit malicious files via remote services such as SSH or FTP, facilitating lateral movement. The detection rule identifies file creation events in these directories by non-root users using common file transfer services, signaling potential unauthorized activity.
+
+### Possible investigation steps
+
+- Review the file creation event details, focusing on the file path to determine if it matches any known malicious patterns or if it is unusual for the environment.
+- Identify the user associated with the file creation event by examining the user.id field, and verify if this user should have access to the affected directory.
+- Investigate the process responsible for the file creation by analyzing the process.name field to determine if it aligns with expected usage patterns for the user and system.
+- Check the source IP address and connection details related to the file transfer service used (e.g., SSH, FTP) to identify any suspicious or unauthorized access attempts.
+- Correlate the event with other recent activities on the host to identify any patterns of lateral movement or other suspicious behavior.
+- Review historical data for similar file creation events by the same user or process to assess if this is part of a recurring pattern or an isolated incident.
+
+### False positive analysis
+
+- Routine administrative tasks: System administrators often use file transfer services like scp or rsync to move files for legitimate purposes. To reduce false positives, create exceptions for known administrative accounts or specific file paths that are regularly used for maintenance.
+- Automated scripts and cron jobs: Automated processes may create temporary files in world-writeable directories. Identify and whitelist these scripts or jobs by their process names or user accounts to prevent unnecessary alerts.
+- Software updates and installations: Some software updates or installations may temporarily use world-writeable directories. Monitor and document these activities, and consider excluding specific update processes or package managers from the rule.
+- Development and testing environments: Developers may use these directories for testing purposes. Establish a separate monitoring policy for development environments or exclude known developer accounts to minimize false positives.
+- Backup operations: Backup tools might use temporary directories for staging files. Identify these tools and their typical behavior, and create exceptions based on their process names or user IDs.
+
+### Response and remediation
+
+- Immediately isolate the affected system from the network to prevent further lateral movement by the adversary.
+- Terminate any suspicious processes associated with file transfer services (e.g., scp, ssh, ftp) that are not part of legitimate user activity.
+- Remove any unauthorized files created in world-writeable directories such as /tmp, /var/tmp, or /dev/shm to eliminate potential threats.
+- Conduct a thorough review of user accounts and permissions, focusing on non-root users who have recently accessed the system, to identify any unauthorized access.
+- Reset credentials for compromised or potentially compromised accounts to prevent further unauthorized access.
+- Monitor network traffic for unusual patterns or connections to external IP addresses that may indicate ongoing or additional compromise attempts.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been affected, ensuring a coordinated response.
+"""
+risk_score = 47
+rule_id = "3e528511-7316-4a6e-83da-61b5f1c07fd4"
+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).
+"""
+severity = "medium"
+tags = [
+    "Domain: Endpoint",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Lateral Movement",
+    "Data Source: Elastic Defend",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "new_terms"
+query = '''
+event.category:file and host.os.type:linux and event.action:creation and
+process.name:(ftp or rsync or scp or sftp or sftp-server or ssh or sshd or vsftpd) and
+file.path:((/dev/shm/* or /tmp* or /var/tmp*) and not (/tmp/ansible-tmp-* or /var/tmp/ansible-tmp-*)) and
+not user.id:0
+'''
+
+[[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 = "T1570"
+name = "Lateral Tool Transfer"
+reference = "https://attack.mitre.org/techniques/T1570/"
+
+[rule.threat.tactic]
+id = "TA0008"
+name = "Lateral Movement"
+reference = "https://attack.mitre.org/tactics/TA0008/"
+
+[rule.new_terms]
+field = "new_terms_fields"
+value = ["process.executable", "host.id"]
+
+[[rule.new_terms.history_window_start]]
+field = "history_window_start"
+value = "now-7d"

nldcsc_elastic_rules/rules/linux/lateral_movement_ssh_it_worm_download.toml

@@ -0,0 +1,141 @@
+[metadata]
+creation_date = "2023/09/21"
+integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"]
+maturity = "production"
+updated_date = "2025/03/20"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies processes that are capable of downloading files with command line arguments containing URLs to SSH-IT's
+autonomous SSH worm. This worm intercepts outgoing SSH connections every time a user uses ssh.
+"""
+from = "now-9m"
+index = [
+    "auditbeat-*",
+    "endgame-*",
+    "logs-auditd_manager.auditd-*",
+    "logs-crowdstrike.fdr*",
+    "logs-endpoint.events.process*",
+    "logs-sentinel_one_cloud_funnel.*",
+]
+language = "eql"
+license = "Elastic License v2"
+name = "Potential SSH-IT SSH Worm Downloaded"
+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 SSH-IT SSH Worm Downloaded
+
+SSH-IT is an autonomous worm that exploits SSH connections to propagate across networks. It hijacks outgoing SSH sessions, allowing adversaries to move laterally within a compromised environment. Attackers often use tools like curl or wget to download the worm from specific URLs. The detection rule identifies these download attempts by monitoring process activities on Linux systems, focusing on command-line arguments that match known malicious URLs, thereby alerting security teams to potential threats.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process name (either curl or wget) and the URL involved in the download attempt to confirm it matches one of the known malicious URLs listed in the query.
+- Check the process execution context, including the user account under which the process was executed, to determine if it was initiated by a legitimate user or potentially compromised account.
+- Investigate the source IP address and hostname of the affected Linux system to understand its role within the network and assess the potential impact of lateral movement.
+- Examine the system's SSH logs to identify any unusual or unauthorized SSH connections that may indicate further compromise or lateral movement attempts.
+- Analyze the network traffic logs for any outbound connections to the identified malicious URLs to confirm whether the download attempt was successful and if any additional payloads were retrieved.
+- Review historical alerts and logs for any previous similar activities on the same host or user account to identify patterns or repeated attempts that may indicate a persistent threat.
+
+### False positive analysis
+
+- Legitimate administrative tasks using curl or wget to download files from the internet may trigger the rule. To manage this, security teams can create exceptions for specific URLs or IP addresses known to be safe and frequently accessed by administrators.
+- Automated scripts or cron jobs that use curl or wget to download updates or configuration files from trusted internal or external sources might be flagged. Users can whitelist these scripts or the specific URLs they access to prevent unnecessary alerts.
+- Development or testing environments where developers frequently download open-source tools or libraries using curl or wget could generate false positives. Implementing a policy to exclude these environments from the rule or setting up a separate monitoring profile for them can help reduce noise.
+- Security tools or monitoring solutions that use curl or wget for health checks or data collection might be mistakenly identified. Identifying these tools and excluding their known benign activities from the rule can help maintain focus on genuine threats.
+
+### Response and remediation
+
+- Immediately isolate the affected host from the network to prevent further lateral movement by the SSH-IT worm.
+- Terminate any suspicious processes identified as using curl or wget with the malicious URLs to stop the download and execution of the worm.
+- Conduct a thorough scan of the isolated host using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any instances of the SSH-IT worm.
+- Review and reset credentials for any SSH accounts that may have been compromised, ensuring the use of strong, unique passwords and considering the implementation of multi-factor authentication (MFA).
+- Analyze network logs and SSH access logs to identify any lateral movement or unauthorized access attempts, and take steps to secure any other potentially compromised systems.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
+- Update firewall and intrusion detection/prevention system (IDS/IPS) rules to block the known malicious URLs and monitor for any future attempts to access them."""
+references = ["https://www.thc.org/ssh-it/"]
+risk_score = 47
+rule_id = "2ddc468e-b39b-4f5b-9825-f3dcb0e998ea"
+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 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 [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: Lateral Movement",
+    "Data Source: Elastic Defend",
+    "Data Source: Elastic Endgame",
+    "Data Source: Auditd Manager",
+    "Data Source: Crowdstrike",
+    "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "eql"
+
+query = '''
+process where host.os.type == "linux" and event.type == "start" and
+ event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
+ process.name in ("curl", "wget") and process.args : (
+  "https://thc.org/ssh-it/x", "http://nossl.segfault.net/ssh-it-deploy.sh", "https://gsocket.io/x",
+  "https://thc.org/ssh-it/bs", "http://nossl.segfault.net/bs"
+)
+'''
+
+
+[[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/"
+

nldcsc_elastic_rules/rules/linux/lateral_movement_ssh_process_launched_inside_container.toml

@@ -0,0 +1,138 @@
+[metadata]
+creation_date = "2025/03/12"
+integration = ["endpoint"]
+maturity = "production"
+updated_date = "2025/03/12"
+
+[rule]
+author = ["Elastic"]
+description = """
+This rule detects an SSH or SSHD process executed from inside a container. This includes both the client ssh binary and
+server ssh daemon process. SSH usage inside a container should be avoided and monitored closely when necessary. With
+valid credentials an attacker may move laterally to other containers or to the underlying host through container
+breakout. They may also use valid SSH credentials as a persistence mechanism.
+"""
+false_positives = [
+    """
+    SSH usage may be legitimate depending on the environment. Access patterns and follow-on activity should be analyzed
+    to distinguish between authorized and potentially malicious behavior.
+    """,
+]
+from = "now-9m"
+index = ["logs-endpoint.events.process*"]
+language = "eql"
+license = "Elastic License v2"
+name = "SSH Process Launched From Inside A Container"
+references = [
+    "https://microsoft.github.io/Threat-Matrix-for-Kubernetes/techniques/SSH%20server%20running%20inside%20container/",
+    "https://www.blackhillsinfosec.com/sshazam-hide-your-c2-inside-of-ssh/",
+]
+risk_score = 47
+rule_id = "5c50ffa6-07f4-4cce-a1b7-c16928a2ed52"
+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: Lateral Movement",
+    "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.entry_leader.entry_meta.type == "container" and process.name in ("sshd", "ssh", "autossh")
+'''
+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 SSH Process Launched From Inside A Container
+
+SSH (Secure Shell) is a protocol used for secure remote access and management of systems. Within container environments, SSH usage is atypical and can signal potential security risks. Adversaries may exploit SSH to move laterally between containers or escape to the host system. The detection rule identifies SSH processes initiated within containers, flagging potential unauthorized access or persistence attempts by monitoring process events and container identifiers.
+
+### Possible investigation steps
+
+- Examine the process start event details, including the process name (sshd, ssh, autossh) and event actions (fork, exec), to understand the context and nature of the SSH activity.
+- Check for any recent changes or deployments related to the container to identify if the SSH process aligns with expected behavior or recent updates.
+- Investigate the source and destination of the SSH connection to determine if it involves unauthorized or suspicious endpoints, potentially indicating lateral movement or an attempt to access the host system.
+- Analyze user accounts and credentials used in the SSH session to verify if they are legitimate and authorized for container access, looking for signs of compromised credentials.
+- Correlate the SSH activity with other security events or alerts to identify patterns or additional indicators of compromise within the container environment.
+
+### False positive analysis
+
+- Development and testing environments may intentionally use SSH for debugging or administrative tasks. Users can create exceptions for specific container IDs or hostnames associated with these environments to reduce noise.
+- Automated scripts or orchestration tools might use SSH to manage containers. Identify these tools and exclude their process IDs or user accounts from triggering the rule.
+- Some legacy applications might rely on SSH for internal communication. Review these applications and whitelist their specific process names or container images to prevent false alerts.
+- Containers running SSH for legitimate remote access purposes, such as maintenance, should be documented. Exclude these containers by their unique identifiers or labels to avoid unnecessary alerts.
+- Regularly review and update the exclusion list to ensure it aligns with current operational practices and does not inadvertently allow malicious activity.
+
+### Response and remediation
+
+- Immediately isolate the affected container to prevent potential lateral movement or further unauthorized access. This can be done by stopping the container or disconnecting it from the network.
+- Conduct a thorough review of the container's logs and environment to identify any unauthorized access or changes. Pay special attention to SSH-related logs and any anomalies in user activity.
+- Revoke any SSH keys or credentials that may have been compromised. Ensure that all SSH keys used within the container environment are rotated and that access is restricted to only necessary personnel.
+- Assess the container image and configuration for vulnerabilities or misconfigurations that may have allowed the SSH process to be initiated. Patch any identified vulnerabilities and update the container image accordingly.
+- Implement network segmentation to limit the ability of containers to communicate with each other and the host system, reducing the risk of lateral movement.
+- Enhance monitoring and alerting for SSH activity within container environments to ensure rapid detection of similar threats in the future. This includes setting up alerts for any SSH process initiation within containers.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems or containers have been affected."""
+
+[[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.tactic]
+id = "TA0008"
+name = "Lateral Movement"
+reference = "https://attack.mitre.org/tactics/TA0008/"
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[[rule.threat.technique]]
+id = "T1133"
+name = "External Remote Services"
+reference = "https://attack.mitre.org/techniques/T1133/"
+
+[rule.threat.tactic]
+id = "TA0003"
+name = "Persistence"
+reference = "https://attack.mitre.org/tactics/TA0003/"

nldcsc_elastic_rules/rules/linux/lateral_movement_telnet_network_activity_external.toml

@@ -0,0 +1,138 @@
+[metadata]
+creation_date = "2020/04/23"
+integration = ["endpoint", "sentinel_one_cloud_funnel"]
+maturity = "production"
+updated_date = "2025/03/20"
+
+[rule]
+author = ["Elastic"]
+description = """
+Telnet provides a command line interface for communication with a remote device or server. This rule identifies Telnet
+network connections to publicly routable IP addresses.
+"""
+false_positives = [
+    """
+    Telnet can be used for both benign or malicious purposes. Telnet is included by default in some Linux distributions,
+    so its presence is not inherently suspicious. The use of Telnet to manage devices remotely has declined in recent
+    years in favor of more secure protocols such as SSH. Telnet usage by non-automated tools or frameworks may be
+    suspicious.
+    """,
+]
+from = "now-9m"
+index = ["logs-endpoint.events.network*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"]
+language = "eql"
+license = "Elastic License v2"
+name = "Connection to External Network via Telnet"
+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 Connection to External Network via Telnet
+
+Telnet is a protocol offering a command-line interface for remote communication, often used for device management. However, its lack of encryption makes it vulnerable to interception, allowing adversaries to exploit it for unauthorized access or data exfiltration. The detection rule identifies Telnet connections to external IPs, flagging potential lateral movement by excluding known internal and reserved IP ranges.
+
+### Possible investigation steps
+
+- Review the alert details to identify the specific process.entity_id and destination IP address involved in the Telnet connection.
+- Verify the legitimacy of the destination IP address by checking if it belongs to a known or trusted external entity, using threat intelligence sources or IP reputation services.
+- Investigate the process details associated with the process.entity_id to determine the user account and command line arguments used during the Telnet session.
+- Check the system logs and user activity on the host to identify any unusual behavior or unauthorized access attempts around the time of the Telnet connection.
+- Assess whether the Telnet connection aligns with expected business operations or if it indicates potential lateral movement or data exfiltration attempts.
+
+### False positive analysis
+
+- Internal device management using Telnet may trigger false positives if the destination IPs are not included in the known internal ranges. Users should verify and update the list of internal IP ranges to include any additional internal networks used for legitimate Telnet connections.
+- Automated scripts or monitoring tools that use Telnet for legitimate purposes can cause false positives. Identify these scripts and consider creating exceptions for their specific IP addresses or process names to prevent unnecessary alerts.
+- Testing environments that simulate external connections for development purposes might be flagged. Ensure that IP addresses used in these environments are documented and excluded from the detection rule to avoid false positives.
+- Legacy systems that rely on Telnet for communication with external partners or services may be mistakenly flagged. Review these systems and, if deemed secure, add their IP addresses to an exception list to reduce false alerts.
+- Misconfigured network devices that inadvertently use Telnet for external communication can trigger alerts. Regularly audit network configurations and update the detection rule to exclude known benign IPs associated with these devices.
+
+### Response and remediation
+
+- Immediately isolate the affected Linux host from the network to prevent further unauthorized access or data exfiltration.
+- Terminate any active Telnet sessions on the affected host to stop ongoing malicious activity.
+- Conduct a thorough review of the affected system's logs and processes to identify any unauthorized changes or additional compromised accounts.
+- Change all passwords associated with the affected system and any other systems that may have been accessed using Telnet.
+- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited.
+- Implement network segmentation to limit Telnet access to only necessary internal systems and block Telnet traffic to external networks.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
+references = ["https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml"]
+risk_score = 47
+rule_id = "e19e64ee-130e-4c07-961f-8a339f0b8362"
+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).
+"""
+severity = "medium"
+tags = [
+    "Domain: Endpoint",
+    "OS: Linux",
+    "Use Case: Threat Detection",
+    "Tactic: Lateral Movement",
+    "Data Source: Elastic Defend",
+    "Data Source: SentinelOne",
+    "Resources: Investigation Guide",
+]
+type = "eql"
+
+query = '''
+sequence by process.entity_id
+  [process where host.os.type == "linux" and process.name == "telnet" and event.type == "start"]
+  [network where host.os.type == "linux" and process.name == "telnet" and not cidrmatch(
+     destination.ip, "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", "192.0.0.0/24", "192.0.0.0/29",
+     "192.0.0.8/32", "192.0.0.9/32", "192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32", "192.0.2.0/24",
+     "192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", "224.0.0.0/4", "100.64.0.0/10",
+     "192.175.48.0/24", "198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", "::1", "FE80::/10",
+     "FF00::/8"
+    )
+  ]
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1021"
+name = "Remote Services"
+reference = "https://attack.mitre.org/techniques/T1021/"
+
+
+[rule.threat.tactic]
+id = "TA0008"
+name = "Lateral Movement"
+reference = "https://attack.mitre.org/tactics/TA0008/"
+