Potential Successful SSH Brute Force Attack via macOS Security Events

Description

Identifies a burst of failed inbound SSH authentication attempts on a macOS host followed shortly by a successful SSH authentication on the same host, using sshd authentication messages collected by the macOS Security Events integration. A successful login immediately after repeated failures indicates that a password brute force or password spraying attack against an exposed SSH service has likely succeeded.

Query · eql

sequence by host.id with maxspan=15s
  [authentication where event.dataset == "macos.authentication" and host.os.type == "macos" and
    macos.event.message.description : ("Failed password for*",
                                      "Failed keyboard-interactive/pam for*",
                                      "error: PAM: authentication error for*")] with runs=10
  [authentication where event.dataset == "macos.authentication" and host.os.type == "macos" and
   macos.event.message.description : "Accepted *"]

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 Successful SSH Brute Force Attack via macOS Security Events

SSH (Secure Shell) is a protocol used to securely access remote systems. On macOS, the sshd-session process logs each failed authentication attempt (Failed password for, Failed keyboard-interactive/pam for, PAM: authentication error for) and each successful one (Accepted <method> for <user> from <ip> port <port>) to the unified log. This rule alerts when ten or more failure messages on a host are followed within 15 seconds by an Accepted message on the same host, indicating that a brute force or password spraying attack has likely succeeded. The sequence is correlated per host; the source IP address and username are present in the message text and must be read from the sequence events.

Possible investigation steps

  • Review the Accepted event in the sequence and read its macos.event.message.description. field to identify the compromised username, the source IP address and port, and the authentication method used.
  • Compare the source IP address and usernames in the failure messages with the Accepted message to confirm the success came from the same source and to determine whether one account or many were targeted.
  • Determine whether the source IP address is internal or external and whether it is associated with known infrastructure, scanners, or previous alerts.
  • Verify whether the compromised account has administrative privileges or is a member of the admin group.
  • Review process activity on the host after the successful login for discovery, persistence, or credential access behavior, using Elastic Defend data if available.
  • Review other alerts and events associated with the affected host and account during the past 48 hours.
  • Determine whether Remote Login is expected to be enabled on this host and whether the account is expected to log in over SSH.

Related rules

  • Potential SSH Brute Force Detected via macOS Security Events - 3751cc17-6e7e-4356-86d5-c8f44aab9a28

False positive analysis

  • Automation or configuration management tooling that retries with stale credentials before succeeding with a valid one can produce a burst of failures followed by a success. Verify the source and exclude known automation if expected.
  • Because correlation is per host, an unrelated successful login within 15 seconds of a failure burst from another source will match. Compare source IP addresses in the failure and Accepted messages to rule this out.
  • A user with an expired or recently rotated password who retries repeatedly before succeeding. The 15-second window and PAM's per-attempt delay make this unlikely from a single interactive session.
  • Security scanners or credential-validation health checks that test SSH authentication against known hosts.

Response and remediation

  • Treat the alert as a potential compromise: a successful login after repeated failures means the attacker likely holds valid credentials for the host.
  • Terminate active SSH sessions for the compromised account and isolate the host from the network if unauthorized access is confirmed.
  • Reset the password of the compromised account and any other accounts sharing the same credential; review the account for unexpected privilege changes, SSH authorized keys, or persistence mechanisms such as launch agents or login items.
  • Review commands executed in the session and on the host for follow-on activity, including data access, lateral movement, or additional accounts created.
  • Block or rate-limit the source IP address at the network perimeter or on the host, and review why the SSH service was reachable from that source.
  • Review and harden the host's SSH configuration: prefer key-based authentication, restrict access with AllowUsers/AllowGroups, and disable Remote Login where it is not required.
  • Search for similar sequences across other macOS hosts to determine whether the activity is part of a broader campaign.
  • Escalate to the incident response team and update logging and detection coverage based on the findings.
Raw source Potential Successful SSH Brute Force Attack 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 burst of failed inbound SSH authentication attempts on a macOS host followed shortly by a successful SSH
authentication on the same host, using sshd authentication messages collected by the macOS Security Events integration.
A successful login immediately after repeated failures indicates that a password brute force or password spraying attack against an
exposed SSH service has likely succeeded.
"""
from = "now-9m"
index = ["logs-macos.authentication-*"]
language = "eql"
license = "Elastic License v2"
name = "Potential Successful SSH Brute Force Attack 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 Successful SSH Brute Force Attack via macOS Security Events

SSH (Secure Shell) is a protocol used to securely access remote systems. On macOS, the `sshd-session` process logs each
failed authentication attempt (`Failed password for`, `Failed keyboard-interactive/pam for`,
`PAM: authentication error for`) and each successful one (`Accepted <method> for <user> from <ip> port <port>`) to the
unified log. This rule alerts when ten or more failure messages on a host are followed within 15 seconds by an
`Accepted` message on the same host, indicating that a brute force or password spraying attack has likely succeeded.
The sequence is correlated per host; the source IP address and username are present in the message text and must be
read from the sequence events.

### Possible investigation steps

- Review the `Accepted` event in the sequence and read its `macos.event.message.description.` field to identify the compromised username, the
source IP address and port, and the authentication method used.
- Compare the source IP address and usernames in the failure messages with the `Accepted` message to confirm the
success came from the same source and to determine whether one account or many were targeted.
- Determine whether the source IP address is internal or external and whether it is associated with known
infrastructure, scanners, or previous alerts.
- Verify whether the compromised account has administrative privileges or is a member of the `admin` group.
- Review process activity on the host after the successful login for discovery, persistence, or credential access
behavior, using Elastic Defend data if available.
- Review other alerts and events associated with the affected host and account during the past 48 hours.
- Determine whether Remote Login is expected to be enabled on this host and whether the account is expected to log in
over SSH.

### Related rules

- Potential SSH Brute Force Detected via macOS Security Events - 3751cc17-6e7e-4356-86d5-c8f44aab9a28

### False positive analysis

- Automation or configuration management tooling that retries with stale credentials before succeeding with a valid one
can produce a burst of failures followed by a success. Verify the source and exclude known automation if expected.
- Because correlation is per host, an unrelated successful login within 15 seconds of a failure burst from another source
will match. Compare source IP addresses in the failure and `Accepted` messages to rule this out.
- A user with an expired or recently rotated password who retries repeatedly before succeeding. The 15-second window and
PAM's per-attempt delay make this unlikely from a single interactive session.
- Security scanners or credential-validation health checks that test SSH authentication against known hosts.

### Response and remediation

- Treat the alert as a potential compromise: a successful login after repeated failures means the attacker likely holds
valid credentials for the host.
- Terminate active SSH sessions for the compromised account and isolate the host from the network if unauthorized
access is confirmed.
- Reset the password of the compromised account and any other accounts sharing the same credential; review the account
for unexpected privilege changes, SSH authorized keys, or persistence mechanisms such as launch agents or login items.
- Review commands executed in the session and on the host for follow-on activity, including data access, lateral
movement, or additional accounts created.
- Block or rate-limit the source IP address at the network perimeter or on the host, and review why the SSH service was
reachable from that source.
- Review and harden the host's SSH configuration: prefer key-based authentication, restrict access with
`AllowUsers`/`AllowGroups`, and disable Remote Login where it is not required.
- Search for similar sequences across other macOS hosts to determine whether the activity is part of a broader campaign.
- Escalate to the incident response team and update logging and detection coverage based on the findings.
"""
references = ["https://themittenmac.com/detecting-ssh-activity-via-process-monitoring/"]
risk_score = 73
rule_id = "f5898b1e-3071-4597-b066-43d298c7b415"
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 = "high"
tags = [
    "OS: macOS",
    "Use Case: Threat Detection",
    "Tactic: Credential Access",
    "Tactic: Initial Access",
    "Data Source: macOS Security Events",
    "Resources: Investigation Guide",
]
type = "eql"
query = '''
sequence by host.id with maxspan=15s
  [authentication where event.dataset == "macos.authentication" and host.os.type == "macos" and
    macos.event.message.description : ("Failed password for*",
                                      "Failed keyboard-interactive/pam for*",
                                      "error: PAM: authentication error for*")] with runs=10
  [authentication where event.dataset == "macos.authentication" and host.os.type == "macos" and
   macos.event.message.description : "Accepted *"]
'''

[[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 = "T1078"
name = "Valid Accounts"
reference = "https://attack.mitre.org/techniques/T1078/"

[[rule.threat.technique.subtechnique]]
id = "T1078.003"
name = "Local Accounts"
reference = "https://attack.mitre.org/techniques/T1078/003/"

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