Log Dejargonizer

Linux Audit Framework · Event USER_AUTH

auditd USER_AUTH: an authentication attempt was recorded

The audit framework recorded an authentication attempt and its result. It covers the same ground as the syslog authentication messages but in a structured, harder-to-tamper-with form, which is why compliance regimes ask for it specifically.

Also written as type=USER_AUTHauditd USER_AUTHaudit user authentication recordUSER_LOGIN auditd

What it means for you

For an analyst

Where auditd is required for compliance, this is usually the record being asked for. It is structured, and the audit log is harder to modify than syslog files. It overlaps heavily with the pam_unix messages — collect one or the other rather than both, unless integrity requirements demand the audit version.

What it looks like

Sanitised. Addresses come from the RFC 5737 documentation ranges.

Sample
type=USER_AUTH msg=audit(1756374077.451:45690): pid=24817 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:authentication acct="admin" exe="/usr/sbin/sshd" hostname=198.51.100.77 addr=198.51.100.77 terminal=ssh res=failed'

The fields that decide it

Everything else in the log line is context.

res
The outcome.
  • successAuthentication succeeded.
  • failedAuthentication was refused.
acct
The account being authenticated.
auid
The login user ID, or 4294967295 when there is no login session yet.
addr / hostname
Where the attempt came from.
terminal
The terminal or service involved.
exe
The binary that performed the authentication, such as /usr/sbin/sshd or /usr/bin/sudo.

Ordinary reasons this happens

Most of the time it is one of these.

  • Ordinary logins and privilege escalations.
  • Scheduled jobs authenticating.
  • A mistyped password.
  • Automation with a stale credential.

When it is not ordinary

Credential guessing.

What gives it awayRepeated res=failed for one account or from one address.

ATT&CK T1110

Account enumeration.

What gives it awayFailures across many different account names from one source.

ATT&CK T1589.002

Escalation attempts from a compromised session.

What gives it awayFailed sudo authentications following an unusual login.

ATT&CK T1548.003

What to do next

  1. Filter to res=failed first.
  2. Read exe to see which service was involved.
  3. Aggregate by account and by source address.
  4. Check for a success from the same source after a run of failures.
  5. Cross-reference against the syslog authentication messages if you collect both.

Queries to run

grep Failed authentications today. The -sv flag filters on success value, which is the field that matters. 
ausearch -m USER_AUTH -sv no -ts today -i
grep The related authentication record types together. 
ausearch -m USER_AUTH,USER_LOGIN,USER_ACCT -ts recent -i | grep 'res=failed'
grep Built-in authentication summary. Faster than writing your own aggregation. 
aureport -au --summary -i

Common questions

What is the difference between auditd USER_AUTH and the pam_unix syslog messages?

They record the same authentication events through different mechanisms. USER_AUTH is structured, goes to the audit log, and is harder to tamper with, which is why compliance regimes often require it. The pam_unix messages are easier to read and already collected almost everywhere. Collecting both is usually duplication unless you specifically need the audit log's integrity properties.

How do I see failed logins with ausearch?

`ausearch -m USER_AUTH -sv no -ts today -i` filters to authentication records with a failed success value, over today, with numeric IDs resolved to names. `aureport -au --summary -i` gives a quicker aggregate view when you just want counts.

Read next

Vendor documentation

Last reviewed 28 August 2026