Potential SSH Brute Force Detected via macOS Security Events

Description

Identifies a high number of failed inbound SSH authentication attempts on a macOS host within a short time window, using sshd authentication messages collected by the macOS Security Events integration. Adversaries may perform password brute force or password spraying against exposed SSH services to obtain unauthorized access.

Query · esql

FROM logs-macos.authentication-*
| WHERE data_stream.dataset == "macos.authentication" and (
    macos.event.message.description LIKE "Failed password for*" or
    macos.event.message.description LIKE "Failed keyboard-interactive/pam for*" or
    macos.event.message.description LIKE "error: PAM: authentication error for*" or
    macos.event.message.description LIKE "Connection closed by invalid user*"
  )
| GROK macos.event.message.description "for (invalid user )?%{NOTSPACE:Esql.user_name_attempt} from %{IP:Esql.source_ip_attempt}"
| GROK macos.event.message.description "closed by invalid user %{NOTSPACE:Esql.user_name_probe} %{IP:Esql.source_ip_probe}"
| EVAL Esql.user_name = COALESCE(Esql.user_name_attempt, Esql.user_name_probe),
        Esql.source_ip = COALESCE(Esql.source_ip_attempt, Esql.source_ip_probe)
| STATS
    Esql.event_count = COUNT(*),
    Esql.user_name_values = VALUES(Esql.user_name),
    Esql.user_name_count = COUNT_DISTINCT(Esql.user_name),
    Esql.source_ip_values = VALUES(Esql.source_ip),
    Esql.source_ip_count = COUNT_DISTINCT(Esql.source_ip)
  BY host.id, host.name
| WHERE Esql.event_count >= 20
| KEEP host.id, host.name, Esql.event_count, Esql.user_name_values, Esql.user_name_count, Esql.source_ip_values, Esql.source_ip_count

Implementation guide

This rule requires data from the macOS Security Events integration. Integration setup instructions: macOS Security Events SSH authentication logging setup instructions: macOS Security Events: SSH Authentication

Analyst notes

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 Brute Force Detected via macOS Security Events

On macOS, the sshd-session process logs every failed authentication attempt to the unified log (Failed password for, Failed keyboard-interactive/pam for, PAM: authentication error for), and connections that probe a non-existent username end with Connection closed by invalid user. This rule counts these failure messages per host and alerts when the number reaches the threshold within the rule window. Successful authentications are not counted. The rule extracts the targeted usernames and source IP addresses from the message text and reports them in the alert as Esql.user_name_values and Esql.source_ip_values, with distinct counts in Esql.user_name_count and Esql.source_ip_count.

Possible investigation steps

  • Review Esql.event_count, Esql.user_name_values, and Esql.source_ip_values in the alert to identify how many attempts occurred and which accounts and sources were involved.
  • Use Esql.user_name_count and Esql.source_ip_count to characterize the activity: many usernames from one source indicates password spraying, one username from one source indicates password guessing, and one username from many sources indicates a distributed attack. Check whether the targeted usernames exist on the host.
  • Check whether any Accepted message from sshd-session follows the failures in logs-macos.authentication-*, which would indicate the attack succeeded.
  • Determine whether the source IP addresses are internal or external and whether they are associated with known infrastructure, scanners, or previous alerts.
  • Determine whether Remote Login is expected to be enabled on this host (for example, build servers or developer workstations).
  • Correlate with other alerts or events from the same host during the same period.

Related rules

  • Potential Successful SSH Brute Force Attack via macOS Security Events - f5898b1e-3071-4597-b066-43d298c7b415

False positive analysis

  • Automation or configuration management tooling with stale or rotated credentials can generate bursts of failures, typically from a single known source IP address against a single service account.
  • Security scanners or credential-validation health checks that test SSH authentication against known hosts.
  • Internet-facing SSH services may receive high volumes of scanning or credential-stuffing traffic from unrelated sources; consider network-level rate limiting or exclusions for known source addresses.
  • Users repeatedly mistyping a password rarely reach the threshold within the window due to PAM's per-attempt delay, but multiple parallel sessions from the same user can approach it.

Response and remediation

  • Block or rate-limit the source IP addresses reported in Esql.source_ip_values at the network perimeter or on the host.
  • Verify no successful authentication followed the failures; if one did, treat the host as potentially compromised and follow the response steps of the successful brute force rule.
  • Reset credentials for the accounts reported in Esql.user_name_values if there is any indication they may be weak or exposed.
  • Review the host's SSH configuration: prefer key-based authentication, restrict access with AllowUsers/AllowGroups, and disable Remote Login where it is not required.
  • Escalate to the security operations team if additional hosts show similar patterns.
Raw source Potential SSH Brute Force Detected via macOS Security Events · Elastic TOML
Esc
Published by elastic/detection-rules ↗, licensed under Elastic License 2.0 ↗. Reproduced here unmodified. 
[metadata]
creation_date = "2026/09/09"
integration = ["macos"]
maturity = "production"
updated_date = "2026/09/09"

[rule]
author = ["Elastic"]
description = """
Identifies a high number of failed inbound SSH authentication attempts on a macOS host within a short time window,
using sshd authentication messages collected by the macOS Security Events integration. Adversaries may perform
password brute force or password spraying against exposed SSH services to obtain unauthorized access.
"""
from = "now-9m"
language = "esql"
license = "Elastic License v2"
name = "Potential SSH Brute Force Detected via macOS Security Events"
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 Brute Force Detected via macOS Security Events

On macOS, the `sshd-session` process logs every failed authentication attempt to the unified log (`Failed password for`, `Failed keyboard-interactive/pam for`,
`PAM: authentication error for`), and connections that probe a non-existent username end with `Connection closed by invalid user`.
This rule counts these failure messages per host and alerts when the number reaches the threshold within the rule window. 
Successful authentications are not counted. The rule extracts the targeted usernames and source IP addresses from the message text and reports them in the alert as `Esql.user_name_values`
and `Esql.source_ip_values`, with distinct counts in `Esql.user_name_count` and `Esql.source_ip_count`.

### Possible investigation steps

- Review `Esql.event_count`, `Esql.user_name_values`, and `Esql.source_ip_values` in the alert to identify how many
attempts occurred and which accounts and sources were involved.
- Use `Esql.user_name_count` and `Esql.source_ip_count` to characterize the activity: many usernames from one source
indicates password spraying, one username from one source indicates password guessing, and one username from many
sources indicates a distributed attack. Check whether the targeted usernames exist on the host.
- Check whether any `Accepted` message from `sshd-session` follows the failures in `logs-macos.authentication-*`, which
would indicate the attack succeeded.
- Determine whether the source IP addresses are internal or external and whether they are associated with known
infrastructure, scanners, or previous alerts.
- Determine whether Remote Login is expected to be enabled on this host (for example, build servers or developer
workstations).
- Correlate with other alerts or events from the same host during the same period.

### Related rules

- Potential Successful SSH Brute Force Attack via macOS Security Events - f5898b1e-3071-4597-b066-43d298c7b415

### False positive analysis

- Automation or configuration management tooling with stale or rotated credentials can generate bursts of failures,
typically from a single known source IP address against a single service account.
- Security scanners or credential-validation health checks that test SSH authentication against known hosts.
- Internet-facing SSH services may receive high volumes of scanning or credential-stuffing traffic from unrelated
sources; consider network-level rate limiting or exclusions for known source addresses.
- Users repeatedly mistyping a password rarely reach the threshold within the window due to PAM's per-attempt delay,
but multiple parallel sessions from the same user can approach it.

### Response and remediation

- Block or rate-limit the source IP addresses reported in `Esql.source_ip_values` at the network perimeter or on the
host.
- Verify no successful authentication followed the failures; if one did, treat the host as potentially compromised and
follow the response steps of the successful brute force rule.
- Reset credentials for the accounts reported in `Esql.user_name_values` if there is any indication they may be weak or
exposed.
- Review the host's SSH configuration: prefer key-based authentication, restrict access with `AllowUsers`/`AllowGroups`,
and disable Remote Login where it is not required.
- Escalate to the security operations team if additional hosts show similar patterns.
"""
references = ["https://themittenmac.com/detecting-ssh-activity-via-process-monitoring/"]
risk_score = 21
rule_id = "3751cc17-6e7e-4356-86d5-c8f44aab9a28"
setup = """## Setup

This rule requires data from the macOS Security Events integration.
Integration setup instructions: [macOS Security Events](https://www.elastic.co/docs/reference/security/prebuilt-rules/integration/macos/macos_security_events)
SSH authentication logging setup instructions: [macOS Security Events: SSH Authentication](https://www.elastic.co/docs/reference/security/prebuilt-rules/integration/macos/macos_security_events_ssh_authentication)
"""
severity = "low"
tags = [
    "OS: macOS",
    "Use Case: Threat Detection",
    "Tactic: Credential Access",
    "Data Source: macOS Security Events",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "esql"
query = '''
FROM logs-macos.authentication-*
| WHERE data_stream.dataset == "macos.authentication" and (
    macos.event.message.description LIKE "Failed password for*" or
    macos.event.message.description LIKE "Failed keyboard-interactive/pam for*" or
    macos.event.message.description LIKE "error: PAM: authentication error for*" or
    macos.event.message.description LIKE "Connection closed by invalid user*"
  )
| GROK macos.event.message.description "for (invalid user )?%{NOTSPACE:Esql.user_name_attempt} from %{IP:Esql.source_ip_attempt}"
| GROK macos.event.message.description "closed by invalid user %{NOTSPACE:Esql.user_name_probe} %{IP:Esql.source_ip_probe}"
| EVAL Esql.user_name = COALESCE(Esql.user_name_attempt, Esql.user_name_probe),
        Esql.source_ip = COALESCE(Esql.source_ip_attempt, Esql.source_ip_probe)
| STATS
    Esql.event_count = COUNT(*),
    Esql.user_name_values = VALUES(Esql.user_name),
    Esql.user_name_count = COUNT_DISTINCT(Esql.user_name),
    Esql.source_ip_values = VALUES(Esql.source_ip),
    Esql.source_ip_count = COUNT_DISTINCT(Esql.source_ip)
  BY host.id, host.name
| WHERE Esql.event_count >= 20
| KEEP host.id, host.name, Esql.event_count, Esql.user_name_values, Esql.user_name_count, Esql.source_ip_values, Esql.source_ip_count
'''

[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1110"
name = "Brute Force"
reference = "https://attack.mitre.org/techniques/T1110/"

[[rule.threat.technique.subtechnique]]
id = "T1110.001"
name = "Password Guessing"
reference = "https://attack.mitre.org/techniques/T1110/001/"

[[rule.threat.technique.subtechnique]]
id = "T1110.003"
name = "Password Spraying"
reference = "https://attack.mitre.org/techniques/T1110/003/"

[rule.threat.tactic]
id = "TA0006"
name = "Credential Access"
reference = "https://attack.mitre.org/tactics/TA0006/"

[[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 = "TA0001"
name = "Initial Access"
reference = "https://attack.mitre.org/tactics/TA0001/"

Detection rules belong to the projects that publish them and remain under their own licenses. This site indexes and links to them; it claims no rights in them.