Detection and Logging

Auth Logs

Authentication logs show who attempted access, from where, and whether it worked. They are essential for spotting brute force, password spraying, suspicious successes, and misuse of privileged accounts.

Learning objectives

What you should be able to do after reading.

Interpret common authentication outcomes and fields such as user, source, method, and reason
Detect brute force, spraying, and suspicious success patterns using simple rules and baselines
Understand why privileged access requires stricter monitoring and faster response

At a glance

Fast mental model before you dive in.

🧠

High value fields

User and account type (human, service, admin)
Source (IP, device, location, logon type)
Target (host, service, application)
Result and reason (success, failure cause)

What to detect first

Repeated failures and password spraying patterns
Success after many failures for the same user
New device or new source for a privileged user
Privilege use shortly after a new login

Fast triage checks

Is the account expected and currently active
Is the source expected for that user
Is the target a system they should access
Is there follow on activity that confirms intent

What to collect

Successful and failed authentication attempts with user, source, host, method, and failure reason
Privilege use and elevation events (for example sudo, admin role use, or new privileged sessions)
MFA and step up authentication events when available, including approvals, denials, and timeouts
Account lifecycle changes such as creation, disablement, password resets, lockouts, and group membership updates

How attackers show up in auth logs

Pattern	What you see	Why it matters	Typical response
Brute force	High volume failures for one account from one or a few sources	Direct guessing against a target account or service	Throttle and block sources, require MFA, and review exposed services
Password spraying	Low rate failures spread across many accounts from one source	Designed to avoid lockout policies while testing common passwords	Detect across users and time windows, block source, and enforce stronger auth
Fail then succeed	A success shortly after multiple failures for the same account	Often indicates guessed credentials or stolen passwords being validated	Investigate the device and session, rotate credentials, and review recent activity
Impossible travel	Logins from distant networks or locations in an unrealistically short time	May indicate token theft, shared accounts, or risky VPN usage	Revoke sessions, require step up authentication, and verify user activity

Make logs actionable

Baseline typical login sources and hours per account so anomalies stand out
Use tighter alert thresholds for high value and admin accounts, and alert on first time access
Correlate sign ins with endpoint, VPN, and firewall data to confirm whether access was expected

Signals to watch for

Patterns worth investigating further.

📡

Many failures for a single user in a short period
One source attempting many different users over time
A privileged account authenticating from a new device or network
Successful login followed by unusual privilege use or outbound connections

DEEP DIVE

▾

How to read an auth event

Auth logs usually describe an attempt and its result. Focus on who tried, from where, to what, how they authenticated, and why it failed if it failed.

In Linux you often see auth records in /var/log/auth.log or /var/log/secure, and on systemd systems the same events can be queried through journald. In Windows, the Security event log captures detailed logon activity such as successful and failed logons.

Separate authentication from authorization. Authentication is proving identity. Authorization is what the identity is allowed to do after login.

Reliable detection patterns

Count based patterns can be useful, but context matters. A burst of failures from one source might be a password spray, or it might be a misconfigured service. Add enrichment like asset criticality, known admin workstations, and expected locations.

Look for sequences that suggest compromise: many failures followed by a success, success from a new device right after a password reset, or privilege use shortly after a new login.

Prefer detections that include a clear next step. For example, pivot from a suspicious login to process activity and network connections on the same host.

Privileged access deserves its own rules

Separate privileged authentication from normal authentication. Admin actions should be rare and well defined, so they are easier to alert on.

Track sudo usage on Linux and privileged group usage on Windows and in cloud control planes. Monitor creation of new admin accounts, new SSH keys, and changes to MFA or access policies.

Use keys or consistent labels in audit rules and searches so you can retrieve the full story quickly during an incident.

Triage that reduces false positives

A fast triage flow asks three questions: is the identity expected, is the source expected, and is the target expected.

Then examine the method and reason code. For example, many failures can be normal if a service is using old credentials, but the same pattern for a human user at unusual hours deserves attention.

Close the loop by checking for follow on activity like new sessions, new processes, remote management tools, or access to sensitive data.

Linux versus Windows versus cloud identity signals

Linux auth telemetry often reflects SSH, sudo, PAM, and local account events. It is strong for spotting brute force attempts, new keys, and privilege escalation through sudo.

Windows identity telemetry can include logon type, authentication package, and target account details, which helps differentiate interactive logons from service logons.

Cloud identity logs often include MFA results, device posture, conditional access decisions, and risky sign in signals. Treat identity as a system across on prem, cloud, VPN, and remote access.

Sessionization and correlation

An auth event is rarely the end of the story. Link it to a session and then to actions. Correlate logons with process creation, remote execution, and access to privileged resources.

If telemetry provides a session identifier, keep it. If not, approximate sessions using user, source, target, and a time window that matches your environment.

Starter hunts

• Top failed logins by user and by source in the last day

• Success after many failures for the same user

• Successful logins for privileged accounts from new sources

• New service accounts or new SSH keys

• Privilege use shortly after a new login