Detect SSH Brute Force Authentication Failures in Linux auditd Logs

title: SSH Brute Force Authentication Failures in auditd
id: 319cdc1d-145d-46c9-8976-d0cd9bcbb1c7
status: experimental
description: >
  Detects a burst of failed SSH authentication attempts recorded by auditd's
  PAM instrumentation for sshd. A single connection attempt that fails
  produces one or more audit records (USER_LOGIN, USER_ERR, USER_AUTH)
  carrying exe="/usr/sbin/sshd" and res=failed; a sustained run of these
  from one source address in a short window is the signature of an
  automated SSH brute-force campaign.
references:
  - https://attack.mitre.org/techniques/T1110/001/
  - https://man7.org/linux/man-pages/man8/auditd.8.html
author: LogTriage
date: 2026/10/26
logsource:
  product: linux
  service: auditd
detection:
  selection:
    exe: '/usr/sbin/sshd'
    res: 'failed'
  timeframe: 5m
  condition: selection | count() by addr >= 10
falsepositives:
  - Misconfigured client or expired keypair producing legitimate failure bursts
  - Authentication testing by vulnerability scanners or monitoring tools
level: high
tags:
  - attack.credential_access
  - attack.t1110.001

What this rule detects

A failed SSH login against a Linux host with auditd enabled does not produce a single log line — it produces a chain of PAM-instrumented audit records: USER_LOGIN when the login attempt is made, USER_ERR with op=PAM:bad_ident when the client’s identity can’t be resolved, and USER_AUTH with op=PAM:authentication when a password is actually checked and rejected. All three carry exe="/usr/sbin/sshd" and res=failed.

A brute-force campaign shows up as a dense run of these records from one source address — far more than the occasional mistyped password produces, and compressed into seconds rather than spread across a normal workday. This rule fires when a single source address accumulates 10 or more failed sshd authentication records within 5 minutes.

Detection logic

The selection is deliberately narrow: exe: '/usr/sbin/sshd' and res: 'failed', with no restriction on type. That is intentional — the three record types sshd failures can land in (USER_LOGIN, USER_ERR, USER_AUTH) are all the same underlying event (a rejected SSH authentication attempt) surfacing at different PAM stages, not separate signals. Restricting to one record type would miss attempts that fail before reaching that stage.

The count groups by addr, the source IP address recorded on each of these records, with a timeframe: 5m. Grouping by address rather than by account name matters here: early attempts in a brute-force run often never resolve to a username at all (acct="(unknown)"), so a per-account count would undercount the campaign.

Validated against a real sample

Validated against auditd_ssh_bruteforce.log (shipped with LogTriage), which shows 26 failed sshd authentication records — 8 USER_LOGIN/USER_ERR pairs with acct="(unknown)", 8 more USER_AUTH records with acct="root", and a final USER_LOGIN failure also for root — all carrying addr=203.0.113.45, spanning roughly 45 seconds. The rule’s count() by addr >= 10 condition is satisfied well before the run ends.

The sample continues past the brute force: a USER_AUTH record with res=success for root from the same address, followed by a bash reverse shell to 203.0.113.45, a useradd call, and auditctl -D removing the host’s own audit rules. This rule does not fire on those later events — they are a separate behavior (post-compromise activity) and belong in separate rules.

It stays silent on auditd_normal.log. That log’s sshd records (USER_ACCT, CRED_ACQ, USER_START, USER_LOGIN, USER_END, USER_LOGOUT) are all res=success; the only res=failed record in the file is a USER_AUTH for sudo (exe="/usr/bin/sudo"), which does not carry exe="/usr/sbin/sshd". No benign record matches both selection fields.

False positives

A client retrying with a stale or rotated SSH key against one host can produce a short burst of legitimate res=failed records from a single address. So can a vulnerability scanner or monitoring tool configured to test SSH authentication paths. Both are distinguishable from a real brute force by checking whether the source address is a known, authorized host and whether the burst stops — a single host correcting a bad key fails a handful of times and then succeeds or stops; an attacker keeps trying.