Connection to External Network via Telnet

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.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2020/04/23"
  3integration = ["endpoint", "sentinel_one_cloud_funnel"]
  4maturity = "production"
  5min_stack_version = "8.13.0"
  6min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration."
  7updated_date = "2025/02/04"
  8
  9[rule]
 10author = ["Elastic"]
 11description = """
 12Telnet provides a command line interface for communication with a remote device or server. This rule identifies Telnet
 13network connections to publicly routable IP addresses.
 14"""
 15false_positives = [
 16    """
 17    Telnet can be used for both benign or malicious purposes. Telnet is included by default in some Linux distributions,
 18    so its presence is not inherently suspicious. The use of Telnet to manage devices remotely has declined in recent
 19    years in favor of more secure protocols such as SSH. Telnet usage by non-automated tools or frameworks may be
 20    suspicious.
 21    """,
 22]
 23from = "now-9m"
 24index = ["logs-endpoint.events.network*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"]
 25language = "eql"
 26license = "Elastic License v2"
 27name = "Connection to External Network via Telnet"
 28references = ["https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml"]
 29risk_score = 47
 30rule_id = "e19e64ee-130e-4c07-961f-8a339f0b8362"
 31setup = """## Setup
 32
 33This rule requires data coming in from one of the following integrations:
 34- Elastic Defend
 35- Auditbeat
 36
 37### Elastic Defend Integration Setup
 38Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.
 39
 40#### Prerequisite Requirements:
 41- Fleet is required for Elastic Defend.
 42- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
 43
 44#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
 45- Go to the Kibana home page and click "Add integrations".
 46- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
 47- Click "Add Elastic Defend".
 48- Configure the integration name and optionally add a description.
 49- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
 50- Select a configuration 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).
 51- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
 52- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
 53For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
 54- Click "Save and Continue".
 55- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
 56For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
 57
 58### Auditbeat Setup
 59Auditbeat 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.
 60
 61#### The following steps should be executed in order to add the Auditbeat on a Linux System:
 62- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages.
 63- 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).
 64- 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).
 65- 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).
 66- 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).
 67"""
 68severity = "medium"
 69tags = [
 70    "Domain: Endpoint",
 71    "OS: Linux",
 72    "Use Case: Threat Detection",
 73    "Tactic: Lateral Movement",
 74    "Data Source: Elastic Defend",
 75    "Data Source: SentinelOne",
 76    "Resources: Investigation Guide",
 77]
 78type = "eql"
 79
 80query = '''
 81sequence by process.entity_id
 82  [process where host.os.type == "linux" and process.name == "telnet" and event.type == "start"]
 83  [network where host.os.type == "linux" and process.name == "telnet" and not cidrmatch(
 84     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",
 85     "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",
 86     "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",
 87     "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",
 88     "FF00::/8"
 89    )
 90  ]
 91'''
 92note = """## Triage and analysis
 93
 94> **Disclaimer**:
 95> 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.
 96
 97### Investigating Connection to External Network via Telnet
 98
 99Telnet 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.
100
101### Possible investigation steps
102
103- Review the alert details to identify the specific process.entity_id and destination IP address involved in the Telnet connection.
104- 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.
105- Investigate the process details associated with the process.entity_id to determine the user account and command line arguments used during the Telnet session.
106- 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.
107- Assess whether the Telnet connection aligns with expected business operations or if it indicates potential lateral movement or data exfiltration attempts.
108
109### False positive analysis
110
111- 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.
112- 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.
113- 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.
114- 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.
115- 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.
116
117### Response and remediation
118
119- Immediately isolate the affected Linux host from the network to prevent further unauthorized access or data exfiltration.
120- Terminate any active Telnet sessions on the affected host to stop ongoing malicious activity.
121- Conduct a thorough review of the affected system's logs and processes to identify any unauthorized changes or additional compromised accounts.
122- Change all passwords associated with the affected system and any other systems that may have been accessed using Telnet.
123- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited.
124- Implement network segmentation to limit Telnet access to only necessary internal systems and block Telnet traffic to external networks.
125- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected."""
126
127
128[[rule.threat]]
129framework = "MITRE ATT&CK"
130[[rule.threat.technique]]
131id = "T1021"
132name = "Remote Services"
133reference = "https://attack.mitre.org/techniques/T1021/"
134
135
136[rule.threat.tactic]
137id = "TA0008"
138name = "Lateral Movement"
139reference = "https://attack.mitre.org/tactics/TA0008/"
...
toml

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.

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.

  • 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.
  • 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.
  • 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

Related rules

to-top