Potential SSH-IT SSH Worm Downloaded

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.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2023/09/21"
  3integration = ["endpoint", "auditd_manager", "crowdstrike", "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 = """
 12Identifies processes that are capable of downloading files with command line arguments containing URLs to SSH-IT's
 13autonomous SSH worm. This worm intercepts outgoing SSH connections every time a user uses ssh.
 14"""
 15from = "now-9m"
 16index = ["auditbeat-*", "endgame-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*"]
 17language = "eql"
 18license = "Elastic License v2"
 19name = "Potential SSH-IT SSH Worm Downloaded"
 20references = ["https://www.thc.org/ssh-it/"]
 21risk_score = 47
 22rule_id = "2ddc468e-b39b-4f5b-9825-f3dcb0e998ea"
 23setup = """## Setup
 24
 25This rule requires data coming in from Elastic Defend.
 26
 27### Elastic Defend Integration Setup
 28Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows
 29the Elastic Agent to monitor events on your host and send data to the Elastic Security app.
 30
 31#### Prerequisite Requirements:
 32- Fleet is required for Elastic Defend.
 33- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
 34
 35#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
 36- Go to the Kibana home page and click "Add integrations".
 37- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
 38- Click "Add Elastic Defend".
 39- Configure the integration name and optionally add a description.
 40- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
 41- 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).
 42- We suggest to select "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
 43- 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.
 44For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
 45- Click "Save and Continue".
 46- 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.
 47For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
 48"""
 49severity = "medium"
 50tags = [
 51    "Domain: Endpoint",
 52    "OS: Linux",
 53    "Use Case: Threat Detection",
 54    "Tactic: Lateral Movement",
 55    "Data Source: Elastic Defend",
 56    "Data Source: Elastic Endgame",
 57    "Data Source: Auditd Manager",
 58    "Data Source: Crowdstrike",
 59    "Data Source: SentinelOne",
 60    "Resources: Investigation Guide",
 61]
 62timestamp_override = "event.ingested"
 63type = "eql"
 64
 65query = '''
 66process where host.os.type == "linux" and event.type == "start" and
 67 event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
 68 process.name in ("curl", "wget") and process.args : (
 69  "https://thc.org/ssh-it/x", "http://nossl.segfault.net/ssh-it-deploy.sh", "https://gsocket.io/x",
 70  "https://thc.org/ssh-it/bs", "http://nossl.segfault.net/bs"
 71)
 72'''
 73note = """## Triage and analysis
 74
 75> **Disclaimer**:
 76> 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.
 77
 78### Investigating Potential SSH-IT SSH Worm Downloaded
 79
 80SSH-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.
 81
 82### Possible investigation steps
 83
 84- 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.
 85- 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.
 86- 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.
 87- Examine the system's SSH logs to identify any unusual or unauthorized SSH connections that may indicate further compromise or lateral movement attempts.
 88- 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.
 89- 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.
 90
 91### False positive analysis
 92
 93- 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.
 94- 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.
 95- 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.
 96- 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.
 97
 98### Response and remediation
 99
100- Immediately isolate the affected host from the network to prevent further lateral movement by the SSH-IT worm.
101- Terminate any suspicious processes identified as using curl or wget with the malicious URLs to stop the download and execution of the worm.
102- 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.
103- 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).
104- 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.
105- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
106- 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."""
107
108
109[[rule.threat]]
110framework = "MITRE ATT&CK"
111[[rule.threat.technique]]
112id = "T1021"
113name = "Remote Services"
114reference = "https://attack.mitre.org/techniques/T1021/"
115[[rule.threat.technique.subtechnique]]
116id = "T1021.004"
117name = "SSH"
118reference = "https://attack.mitre.org/techniques/T1021/004/"
119
120
121[[rule.threat.technique]]
122id = "T1563"
123name = "Remote Service Session Hijacking"
124reference = "https://attack.mitre.org/techniques/T1563/"
125[[rule.threat.technique.subtechnique]]
126id = "T1563.001"
127name = "SSH Hijacking"
128reference = "https://attack.mitre.org/techniques/T1563/001/"
129
130
131
132[rule.threat.tactic]
133id = "TA0008"
134name = "Lateral Movement"
135reference = "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.

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.

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

Related rules

to-top