A finance director reports that the company's draft acquisition plan has turned up in a competitor's hands. Nobody saw it leave, but plenty of systems were watching: a badge reader, a domain controller, a file server, a web proxy and a mail gateway each wrote down a small piece of what happened. The investigation comes down to knowing which log holds which piece and reading it correctly.
On the CompTIA Security+ SY0-801 exam this sits under objective 4.8, which expects you to pick and interpret the right data to support an investigation given a scenario. Be ready to read log excerpts, not just recognize log names. This lesson walks through each type of log and trace data the objective names, shows what real entries look like, and explains what each can and cannot prove. Flow data, packet captures and other sources are the next lesson.
Each log type answers a different investigative question
A log is a record a system writes as it works. A trace is similar but follows one transaction across several systems, such as an email message trace from gateway to mailbox. An investigation starts with a question (who, what, when, where, how) and goes to the source whose job is to record that answer.
| Log type | Typical sources | Question it answers |
|---|---|---|
| Authentication | Domain controllers, sshd, identity provider | Who proved their identity, how and from where? |
| Access and accounting | File servers, VPN and RADIUS, badge readers | What did that identity reach, and for how long? |
| Audit | OS security log, cloud control plane, auditd | Who changed accounts, rights or settings? |
| Network | Firewall, proxy, DNS server | Where did traffic go, and was it allowed? |
| Endpoint | EDR agent, Sysmon | What ran on the machine? |
| Server and application | Web servers, databases, business apps | What did the service do with each request? |
| Device | Routers, switches, printers, IoT | What happened on the infrastructure itself? |
| Communication | Mail gateway, VoIP, chat platform | Who contacted whom, and when? |
| Metadata | Email headers, file properties, EXIF | Where did this artifact come from? |
The categories overlap. A failed Windows logon is an authentication event, and it lands in the Security log, which is also the audit log. The exam doesn't grade rigid boundaries; it grades whether you go to the log that can answer the question. Remember too that a log only exists if someone turned it on. Windows file access auditing is off by default, many applications record only errors, and DNS query logging is often disabled for performance. Deciding what to collect belongs to the monitoring section; here you work with what was collected.
Authentication logs show who signed in, how, and from where
On Windows, every successful logon writes event ID 4624 to the Security log of the machine that accepted it. The field investigators read first is the logon type, because it tells you how the person got in:
Event ID 4624 An account was successfully logged on.
Time: 2026-10-14 02:09:51
Logon Type: 10
Account Name: mbrooks
Workstation: CONTRACTOR-PC
Source Network Address: 10.8.0.41
| Logon type | Name | What it means |
|---|---|---|
| 2 | Interactive | Credentials typed at the machine's own keyboard |
| 3 | Network | Access to a share, mapped drive or other network service |
| 10 | RemoteInteractive | A Remote Desktop session |
Other types exist (4 for scheduled tasks, 5 for services, 7 for a workstation unlock, 11 for cached credentials), but 2, 3 and 10 carry most scenarios. A type 2 logon usually means someone was at the keyboard, or at a virtual machine's console. A burst of type 3 logons from one workstation to many servers suggests lateral movement or scanning. A type 10 from an address outside your ranges means remote desktop is reachable from somewhere it shouldn't be.
Failures are event ID 4625, and the sub status code explains the failure. 0xC0000064 means the user name doesn't exist; 0xC000006A means the name is real and the password is wrong. Hundreds of 0xC0000064 failures for names like admin and test point to an attacker guessing names. Many 0xC000006A failures spread across real accounts point to password spraying with a valid user list. One quirk: with Network Level Authentication enabled, failed Remote Desktop attempts are typically logged as type 3, because the credentials are checked before the session starts. When an account trips the lockout threshold, the domain controller writes event ID 4740, and its Caller Computer Name field shows where the bad attempts came from.
Linux systems record the same story in text. On Debian and Ubuntu it's /var/log/auth.log, on Red Hat family systems /var/log/secure, and on journal-only systems you query it with journalctl:
Oct 14 02:13:07 web01 sshd[2231]: Failed password for invalid user admin from 203.0.113.50 port 51234 ssh2
Oct 14 02:13:09 web01 sshd[2233]: Failed password for root from 203.0.113.50 port 51240 ssh2
Oct 14 02:31:44 web01 sshd[2410]: Accepted password for deploy from 203.0.113.50 port 52011 ssh2
Oct 14 02:31:44 web01 sshd[2410]: pam_unix(sshd:session): session opened for user deploy(uid=1002) by (uid=0)
Oct 14 02:33:15 web01 sudo: deploy : TTY=pts/0 ; PWD=/home/deploy ; USER=root ; COMMAND=/usr/bin/cat /etc/shadow
Read it in order. "Invalid user" means the name doesn't exist on the box. The same source address that was guessing later gets "Accepted password" for deploy, so the guessing worked, and it worked against password authentication, not a key. Two minutes later deploy uses sudo to read the password hash file. That is a compromise with privilege use, in five lines.