IMPORTANT: No additional bug fixes or documentation updates will be released for this version. For the latest information, see the current release documentation.
« Potential Internal Linux SSH Brute Force Detected Linux Group Creation »
Elastic Docs ›Elastic Security Solution [8.11] ›Downloadable rule update v8.11.13

Potential Successful SSH Brute Force Attack

edit

Potential Successful SSH Brute Force Attack

edit

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.

Rule type: eql

Rule indices:

  • auditbeat-*
  • filebeat-*
  • logs-system.auth-*

Severity: high

Risk score: 73

Runs every: 5m

Searches indices from: now-9m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References: None

Tags:

  • Domain: Endpoint
  • OS: Linux
  • Use Case: Threat Detection
  • Tactic: Credential Access

Version: 11

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

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

Setup

edit

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.
  • To run Auditbeat on Docker follow the setup instructions in the helper guide.
  • To run Auditbeat on Kubernetes follow the setup instructions in the helper guide.
  • For complete “Setup and Run Auditbeat” information refer to the helper guide.

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.
  • To run Filebeat on Docker follow the setup instructions in the helper guide.
  • To run Filebeat on Kubernetes follow the setup instructions in the helper guide.
  • For quick start information for Filebeat refer to the helper guide.
  • For complete “Setup and Run Filebeat” information refer to the helper guide.

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.

Rule query

edit
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 != "::" ]

Framework: MITRE ATT&CKTM

« Potential Internal Linux SSH Brute Force Detected Linux Group Creation »