Potential Successful SSH Brute Force Attack via macOS Security Events

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.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2026/09/09"
  3integration = ["macos"]
  4maturity = "production"
  5updated_date = "2026/09/18"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Identifies a burst of failed inbound SSH authentication attempts on a macOS host followed shortly by a successful SSH
 11authentication on the same host, using sshd authentication messages collected by the macOS Security Events integration.
 12A successful login immediately after repeated failures indicates that a password brute force or password spraying attack against an
 13exposed SSH service has likely succeeded.
 14"""
 15from = "now-9m"
 16index = ["logs-macos.authentication-*"]
 17language = "eql"
 18license = "Elastic License v2"
 19name = "Potential Successful SSH Brute Force Attack via macOS Security Events"
 20note = """## Triage and analysis
 21
 22> **Disclaimer**:
 23> 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.
 24
 25### Investigating Potential Successful SSH Brute Force Attack via macOS Security Events
 26
 27SSH (Secure Shell) is a protocol used to securely access remote systems. On macOS, the `sshd-session` process logs each
 28failed authentication attempt (`Failed password for`, `Failed keyboard-interactive/pam for`,
 29`PAM: authentication error for`) and each successful one (`Accepted <method> for <user> from <ip> port <port>`) to the
 30unified log. This rule alerts when ten or more failure messages on a host are followed within 15 seconds by an
 31`Accepted` message on the same host, indicating that a brute force or password spraying attack has likely succeeded.
 32The sequence is correlated per host; the source IP address and username are present in the message text and must be
 33read from the sequence events.
 34
 35### Possible investigation steps
 36
 37- Review the `Accepted` event in the sequence and read its `macos.event.message.description.` field to identify the compromised username, the
 38source IP address and port, and the authentication method used.
 39- Compare the source IP address and usernames in the failure messages with the `Accepted` message to confirm the
 40success came from the same source and to determine whether one account or many were targeted.
 41- Determine whether the source IP address is internal or external and whether it is associated with known
 42infrastructure, scanners, or previous alerts.
 43- Verify whether the compromised account has administrative privileges or is a member of the `admin` group.
 44- Review process activity on the host after the successful login for discovery, persistence, or credential access
 45behavior, using Elastic Defend data if available.
 46- Review other alerts and events associated with the affected host and account during the past 48 hours.
 47- Determine whether Remote Login is expected to be enabled on this host and whether the account is expected to log in
 48over SSH.
 49
 50### Related rules
 51
 52- Potential SSH Brute Force Detected via macOS Security Events - 3751cc17-6e7e-4356-86d5-c8f44aab9a28
 53
 54### False positive analysis
 55
 56- Automation or configuration management tooling that retries with stale credentials before succeeding with a valid one
 57can produce a burst of failures followed by a success. Verify the source and exclude known automation if expected.
 58- Because correlation is per host, an unrelated successful login within 15 seconds of a failure burst from another source
 59will match. Compare source IP addresses in the failure and `Accepted` messages to rule this out.
 60- A user with an expired or recently rotated password who retries repeatedly before succeeding. The 15-second window and
 61PAM's per-attempt delay make this unlikely from a single interactive session.
 62- Security scanners or credential-validation health checks that test SSH authentication against known hosts.
 63
 64### Response and remediation
 65
 66- Treat the alert as a potential compromise: a successful login after repeated failures means the attacker likely holds
 67valid credentials for the host.
 68- Terminate active SSH sessions for the compromised account and isolate the host from the network if unauthorized
 69access is confirmed.
 70- Reset the password of the compromised account and any other accounts sharing the same credential; review the account
 71for unexpected privilege changes, SSH authorized keys, or persistence mechanisms such as launch agents or login items.
 72- Review commands executed in the session and on the host for follow-on activity, including data access, lateral
 73movement, or additional accounts created.
 74- Block or rate-limit the source IP address at the network perimeter or on the host, and review why the SSH service was
 75reachable from that source.
 76- Review and harden the host's SSH configuration: prefer key-based authentication, restrict access with
 77`AllowUsers`/`AllowGroups`, and disable Remote Login where it is not required.
 78- Search for similar sequences across other macOS hosts to determine whether the activity is part of a broader campaign.
 79- Escalate to the incident response team and update logging and detection coverage based on the findings.
 80"""
 81references = ["https://themittenmac.com/detecting-ssh-activity-via-process-monitoring/"]
 82risk_score = 73
 83rule_id = "f5898b1e-3071-4597-b066-43d298c7b415"
 84setup = """## Setup
 85
 86This rule requires data from the macOS Security Events integration.
 87Integration setup instructions: [macOS Security Events](https://www.elastic.co/docs/reference/security/prebuilt-rules/integration/macos/macos_security_events)
 88SSH 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)
 89"""
 90severity = "high"
 91tags = [
 92    "OS: macOS",
 93    "Use Case: Threat Detection",
 94    "Tactic: Credential Access",
 95    "Tactic: Initial Access",
 96    "Data Source: macOS Security Events",
 97    "Resources: Investigation Guide",
 98    "Rule Type: Event Correlation (EQL)",
 99    "Platform: macOS",
100    "Domain: Endpoint",
101]
102type = "eql"
103query = '''
104sequence by host.id with maxspan=15s
105  [authentication where event.dataset == "macos.authentication" and host.os.type == "macos" and
106    macos.event.message.description : ("Failed password for*",
107                                      "Failed keyboard-interactive/pam for*",
108                                      "error: PAM: authentication error for*")] with runs=10
109  [authentication where event.dataset == "macos.authentication" and host.os.type == "macos" and
110   macos.event.message.description : "Accepted *"]
111'''
112
113[[rule.threat]]
114framework = "MITRE ATT&CK"
115
116[[rule.threat.technique]]
117id = "T1110"
118name = "Brute Force"
119reference = "https://attack.mitre.org/techniques/T1110/"
120
121[[rule.threat.technique.subtechnique]]
122id = "T1110.001"
123name = "Password Guessing"
124reference = "https://attack.mitre.org/techniques/T1110/001/"
125
126[[rule.threat.technique.subtechnique]]
127id = "T1110.003"
128name = "Password Spraying"
129reference = "https://attack.mitre.org/techniques/T1110/003/"
130
131[rule.threat.tactic]
132id = "TA0006"
133name = "Credential Access"
134reference = "https://attack.mitre.org/tactics/TA0006/"
135
136[[rule.threat]]
137framework = "MITRE ATT&CK"
138
139[[rule.threat.technique]]
140id = "T1078"
141name = "Valid Accounts"
142reference = "https://attack.mitre.org/techniques/T1078/"
143
144[[rule.threat.technique.subtechnique]]
145id = "T1078.003"
146name = "Local Accounts"
147reference = "https://attack.mitre.org/techniques/T1078/003/"
148
149[rule.threat.tactic]
150id = "TA0001"
151name = "Initial Access"
152reference = "https://attack.mitre.org/tactics/TA0001/"```

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

Related rules

to-top