Authentication, Windows & Linux Logs

1🔑 Authentication Log Patterns

Authentication logs matter enormously across IT, IAM and cybersecurity roles. Typical events: LOGIN_ATTEMPT, LOGIN_SUCCESS, LOGIN_FAILED, PASSWORD_INVALID, ACCOUNT_LOCKED, MFA_REQUIRED, MFA_SENT, MFA_APPROVED, MFA_DENIED, TOKEN_ISSUED, TOKEN_REVOKED, SESSION_CREATED, SESSION_EXPIRED, LOGOUT. A modern login might generate this whole sequence:

10:00:01 LOGIN_ATTEMPT user=alice
10:00:01 PASSWORD_VALID user=alice
10:00:02 MFA_REQUIRED user=alice
10:00:02 PUSH_SENT device=iphone123
10:00:17 MFA_APPROVED device=iphone123
10:00:17 TOKEN_ISSUED client=portal
10:00:17 SESSION_CREATED id=ABC123

One failed login is usually normal — people mistype passwords constantly. But consider:

10:21:31 bob INVALID_PASSWORD
10:21:32 alice INVALID_PASSWORD
10:21:32 james INVALID_PASSWORD
10:21:33 sarah INVALID_PASSWORD
10:21:33 admin INVALID_PASSWORD

all from the same source IP within two seconds. Individually, none of these five events looks alarming. The pattern across the events — many different accounts, one source, minimal time between attempts — is what suggests password spraying (Module 8, Section 8; Module 9, Lesson 1). This is the exact same lesson Lesson 1 taught about correlation, now applied specifically to authentication.

2🔑 Authentication Technologies You'll Encounter

Understanding a log genuinely requires understanding the underlying authentication protocol behind it — a Kerberos failure and an OAuth failure can both say "authentication failed" while meaning completely different things underneath.

3🪝 Windows Event Viewer & Logs

Windows records operating system and application events through the Windows Event Log service, viewed via Event Viewer (eventvwr.msc). The main logs: Application (app crashes, database client errors, service errors, .NET failures), Security (logons, logon failures, account creation, group changes, privilege use, process creation), System (service failures, driver problems, shutdown events, hardware errors), and Setup (installation/configuration events).

Windows events carry an Event ID:

Don't try to memorise every Event ID — the important skill is understanding what an event represents and knowing how to investigate it further.

4🔍 Investigating a Windows Failed Logon

A 4625 event might contain Account Name: administrator, Source Network Address: 192.168.1.55, Logon Type: 3, Failure Reason: Unknown user name or bad password. The analyst should ask: who owns 192.168.1.55? Was administrator supposed to log into this machine? How many failures occurred? Were other accounts targeted? Did a successful login follow? What process initiated the authentication?

Logon Type provides critical context: 2 Interactive, 3 Network, 4 Batch, 5 Service, 7 Unlock, 8 NetworkCleartext, 9 NewCredentials, 10 RemoteInteractive, 11 CachedInteractive. Type 10 often indicates Remote Desktop; Type 3 commonly represents network authentication (e.g. accessing a file share). The same Event ID with a different logon type can mean a completely different kind of access attempt.

5🔧 Filtering, PowerShell & EVTX Files

Production Windows servers generate huge event volumes — filter by Event ID (e.g. 4625 for failed logons), time, event source, severity, keywords, user, or computer. Logs don't have to be investigated through the GUI:

# Recent security events
Get-WinEvent -LogName Security -MaxEvents 20

# Failed logons specifically
Get-WinEvent -FilterHashtable @{
    LogName='Security'
    Id=4625
}

PowerShell becomes especially valuable when investigating many machines at once — a skill that connects directly to Module 13's Lesson 4 PowerShell content, and to the dedicated PowerShell module later in the course.

Windows Event Logs are normally stored as .evtx files under C:\Windows\System32\winevt\Logs\ — Security.evtx, System.evtx, Application.evtx. Incident response teams routinely collect these EVTX files for offline analysis (Module 12, Lesson 1's evidence preservation).

6👁️ Sysmon

Microsoft Sysinternals Sysmon gives far richer endpoint telemetry than standard Windows logging — process creation, network connections, driver loading, DLL loading, file creation, registry activity, DNS queries, and process access, depending on configuration. A commonly investigated event is Sysmon Event ID 1 (process creation), e.g.:

Image: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
CommandLine: powershell.exe -EncodedCommand ...

This is exactly the kind of line worth further investigation — Module 11, Lesson 4 covers Sysmon's role in SOC detection in more depth.

7🐩 Linux Logging Locations

Linux logging varies by distribution, system age, logging daemon, and application configuration — you'll meet syslog, rsyslog, syslog-ng, systemd-journald, and application-specific logs. Many logs live under /var/log/: /var/log/messages, /var/log/syslog, /var/log/auth.log, /var/log/secure, /var/log/kern.log, /var/log/cron — though not every distribution uses exactly the same files.

On Debian/Ubuntu, authentication events commonly appear in /var/log/auth.log:

Aug 30 09:22:11 server01 sshd[8217]:
Failed password for invalid user admin from 203.0.113.44 port 53121 ssh2

This tells you: service SSH, result failed password, username admin, source IP 203.0.113.44, source port 53121, protocol SSH2 — every field readable at a glance once you know the format. On RHEL/CentOS/Rocky/AlmaLinux, authentication events typically appear in /var/log/secure instead, with general system events historically in /var/log/messages.

8💻 systemd Journal & Command-Line Investigation

Modern Linux distributions frequently use systemd-journald, queried with journalctl:

journalctl                    # recent events
journalctl -u ssh              # events for the SSH unit (or -u sshd)
journalctl --since today       # today's events only
journalctl -n 100               # last 100 events
journalctl -f                   # follow events live

A handful of simple commands cover most investigation needs: cat application.log displays a whole file (not ideal for large files); less application.log is better for navigating large files, with /error to search inside it; tail application.log shows the last lines, and tail -f application.log follows it live; grep "ERROR" application.log searches, with -i for case-insensitive matching. Commands combine well with pipes, e.g. grep "Failed password" /var/log/auth.log | tail -20 — though piping through cat first (cat application.log | grep ERROR) is usually unnecessary; grep ERROR application.log alone does the same thing more efficiently.

Lesson Outcome

You should now be able to recognise authentication event patterns and spot password spraying from the shape of the events rather than any single line, navigate Windows Event Viewer and interpret key Event IDs and logon types, query Windows logs from PowerShell and locate EVTX files, explain what Sysmon adds, and read Linux authentication logs and use journalctl/grep/tail to investigate them from the command line. Lesson 4 moves beyond the operating system to application, network, cloud and database logs.