authentication events

Overview

Authentication logs record every attempt to prove identity: who tried to log in, from where, and whether it worked. They are among the most valuable logs in any investigation because attackers almost always have to authenticate somewhere to make progress. In a CTF forensics challenge, the auth log is frequently where the story starts — a burst of failures, then one success. This lesson teaches you to read failed and successful login events, and to recognize the patterns that reveal brute-force and related credential attacks.

You practice this on provided or self-generated logs in an authorized, isolated lab. The skill is defensive: spotting the signature of an attack in the record it leaves behind.

Learning objectives

• Read failed and successful authentication events in common log formats.
• Distinguish a normal login pattern from an attack pattern.
• Recognize brute-force, password-spraying, and credential-stuffing signatures in logs.
• Identify the pivotal "many failures then a success" moment that often marks a compromise.

Core concept

An authentication event is a log record of an identity check. Each one carries a few crucial facts: the outcome (success or failure), the account targeted, the source (IP address or host), and the time. Individually these lines are mundane. Their power comes from aggregation: counting failures per source, per account, and per unit of time turns raw lines into a picture of intent. A single failed login is a typo; two hundred failures in a minute from one address is an attack.

The event you most want to find is the transition: a long run of failures for an account followed by a success from the same source. That transition is the classic signature of a brute-force attack that eventually guessed the password.

How it works

What the lines look like. On Linux, SSH authentication events appear in the auth log (syslog format):

Sep 25 14:03:11 web01 sshd[2451]: Failed password for root from 203.0.113.9 port 51222 ssh2
Sep 25 14:03:12 web01 sshd[2452]: Failed password for root from 203.0.113.9 port 51231 ssh2
Sep 25 14:03:14 web01 sshd[2453]: Failed password for root from 203.0.113.9 port 51245 ssh2
Sep 25 14:03:29 web01 sshd[2467]: Accepted password for root from 203.0.113.9 port 51410 ssh2

Read the outcome word (Failed vs Accepted), the account (root), and the source IP. Here, three rapid failures against root from 203.0.113.9 are followed 15 seconds later by an Accepted from the same IP against the same account — a textbook brute-force success. A structured app might log the same story as JSON:

{"time":"2025-09-25T14:03:29Z","event":"login_success","user":"root","src_ip":"203.0.113.9"}

Attack signatures. The shape of the failures tells you which attack it is:

• Brute force — many password attempts against one account from one source in a short window. Signature: high failure count, single username, single (or few) source IPs, tight timing.
• Password spraying — a few attempts each against many accounts, staying under per-account lockout thresholds. Signature: low failures per account but the same source touching a large number of usernames.
• Credential stuffing — trying known username/password pairs (often leaked elsewhere) across many accounts. Signature: many accounts, often many source IPs, frequently one attempt per pair, and sometimes a scattering of successes.

How you detect them. You aggregate: group failures by source IP, by target account, and by time bucket. A spike in failures from one IP against one account screams brute force; a spread of single failures across many accounts from one IP screams spraying. Then you look for any success that follows the failures from the same source — that is the moment to investigate hardest.

Practical example

A CTF challenge hands you an auth.log. You count failed logins per source IP and find 203.0.113.9 responsible for 480 failures in four minutes — overwhelmingly against the account admin. That concentration (one IP, one account, huge count, tight window) is a brute-force signature. You then filter for Accepted/login_success from that IP and find a single success at 14:07:41Z for admin. That success line, sitting at the end of the failure burst, is the compromise — and its timestamp becomes the pivot for the rest of your timeline. The flag or the answer to the challenge is almost always tied to that event: the account, the source, or the exact time it succeeded.

Cybersecurity relevance

Authentication logs are the primary evidence for detecting account compromise, one of the most common ways real intrusions begin. Security teams build detections directly on these patterns: alert when failures from one source exceed a threshold, alert when many accounts are targeted from one IP (spraying), and alert loudly on a success following a failure burst. Defenses that these patterns motivate include account lockouts, rate limiting, multi-factor authentication (which makes a guessed password insufficient), and monitoring for logins from unusual locations. For an analyst, mastering auth-event reading means you can answer the questions every incident asks: Was an account compromised? Which one? From where? When?

Common mistakes

• Looking only at successes. The failures reveal the method and scope; ignoring them hides the attack pattern.
• Not aggregating. One failed login is noise; the signal is in the counts per source, per account, and per time window.
• Missing the transition. The single Accepted line buried in a wall of Failed lines is the most important event — don't scroll past it.
• Confusing spraying with brute force. Few failures per account across many accounts is spraying, not brute force; the response differs.
• Ignoring source IP grouping. Distributed attacks spread failures across many IPs; group by account and by pair, not only by IP.

Key takeaways

• An authentication event carries outcome, account, source, and time; value comes from aggregating these, not reading lines singly.
• Read the outcome word (Failed/Accepted, login_failed/login_success), the target account, and the source IP.
• Brute force = many attempts, one account, one source; spraying = few attempts across many accounts from one source; stuffing = known pairs across many accounts, often many sources.
• The failures-then-success transition from the same source is the signature of a successful compromise and usually the crux of the challenge.
• These patterns drive real defenses: lockouts, rate limiting, MFA, and location-based alerting.

Check your understanding

• You see 300 failed SSH logins against the single account root from one IP in two minutes, then one Accepted from that IP. What happened, and which log line matters most?
• How do the log signatures of password spraying and brute force differ, and why does spraying evade per-account lockouts?
• Why is aggregating authentication events (by source, account, and time) more informative than reading individual lines?