Potential Successful SSH Brute Force Attack

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.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2022/09/14"
  3integration = ["system"]
  4maturity = "production"
  5min_stack_comments = "New fields added: required_fields, related_integrations, setup"
  6min_stack_version = "8.3.0"
  7updated_date = "2023/11/02"
  8
  9[rule]
 10author = ["Elastic"]
 11description = """
 12Identifies multiple SSH login failures followed by a successful one from the same source address. Adversaries can attempt
 13to login into multiple users with a common or known password to gain access to accounts.
 14"""
 15from = "now-9m"
 16index = ["auditbeat-*",  "filebeat-*", "logs-system.auth-*"]
 17language = "eql"
 18license = "Elastic License v2"
 19name = "Potential Successful SSH Brute Force Attack"
 20note = """## Triage and analysis
 21
 22### Investigating Potential Successful SSH Brute Force Attack
 23
 24The 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.
 25
 26#### Possible investigation steps
 27
 28- Investigate the login failure user name(s).
 29- Investigate the source IP address of the failed ssh login attempt(s).
 30- Investigate other alerts associated with the user/host during the past 48 hours.
 31- Identify the source and the target computer and their roles in the IT environment.
 32
 33### False positive analysis
 34
 35- Authentication misconfiguration or obsolete credentials.
 36- Service account password expired.
 37- Infrastructure or availability issue.
 38
 39### Response and remediation
 40
 41- Initiate the incident response process based on the outcome of the triage.
 42- Ensure active session(s) on the host(s) are terminated as the attacker could have gained initial access to the system(s).
 43- Isolate the involved hosts to prevent further post-compromise behavior.
 44- 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.
 45- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.
 46- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
 47- 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).
 48"""
 49risk_score = 73
 50rule_id = "8cb84371-d053-4f4f-bce0-c74990e28f28"
 51setup = """## Setup
 52
 53This rule requires data coming in from one of the following integrations:
 54- Auditbeat
 55- Filebeat
 56
 57### Auditbeat Setup
 58Auditbeat 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.
 59
 60#### The following steps should be executed in order to add the Auditbeat on a Linux System:
 61- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages.
 62- 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).
 63- 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).
 64- 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).
 65- 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).
 66
 67### Filebeat Setup
 68Filebeat 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.
 69
 70#### The following steps should be executed in order to add the Filebeat on a Linux System:
 71- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages.
 72- 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).
 73- 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).
 74- 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).
 75- 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).
 76- 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).
 77
 78#### Rule Specific Setup Note
 79- This rule requires the “Filebeat System Module” to be enabled.
 80- The system module collects and parses logs created by the system logging service of common Unix/Linux based distributions.
 81- 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).
 82"""
 83severity = "high"
 84tags = [
 85        "Domain: Endpoint",
 86        "OS: Linux",
 87        "Use Case: Threat Detection",
 88        "Tactic: Credential Access"
 89        ]
 90type = "eql"
 91query = '''
 92sequence by host.id, source.ip, user.name with maxspan=15s
 93  [authentication where host.os.type == "linux" and event.action  in ("ssh_login", "user_login") and
 94   event.outcome == "failure" and source.ip != null and source.ip != "0.0.0.0" and source.ip != "::" ] with runs=10
 95
 96  [authentication where host.os.type == "linux" and event.action  in ("ssh_login", "user_login") and
 97   event.outcome == "success" and source.ip != null and source.ip != "0.0.0.0" and source.ip != "::" ]
 98'''
 99
100[[rule.threat]]
101framework = "MITRE ATT&CK"
102
103[[rule.threat.technique]]
104id = "T1110"
105name = "Brute Force"
106reference = "https://attack.mitre.org/techniques/T1110/"
107
108[[rule.threat.technique.subtechnique]]
109id = "T1110.001"
110name = "Password Guessing"
111reference = "https://attack.mitre.org/techniques/T1110/001/"
112
113[[rule.threat.technique.subtechnique]]
114id = "T1110.003"
115name = "Password Spraying"
116reference = "https://attack.mitre.org/techniques/T1110/003/"
117
118[rule.threat.tactic]
119id = "TA0006"
120name = "Credential Access"
121reference = "https://attack.mitre.org/tactics/TA0006/"

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

Related rules

to-top