Tony CantaveMy CompTIA CySA+ Notes on Reading Logs Without Drowning in Them
By Tony Cantave ·
When I studied for CompTIA CySA+, the part that changed how I work was not a tool or an acronym. It was learning how to read logs without trying to read everything. A single server can write thousands of lines an hour. If you open that file and start scrolling, you will either give up or miss the one line that mattered. These are the notes I kept, cleaned up so they are useful to anyone studying for the exam or just trying to understand what their own systems are telling them.
Start with a question, not a file
The biggest lesson: never open a log just to "see what is in there." Start with a question you can answer. Did anyone fail to log in more than a few times today? Was a new user account created? Did a service stop and restart when nobody was working? A question tells you which log to open and which lines to keep. Everything else is background noise for that moment.
On a Linux server, login activity usually lives in an authentication log, such as /var/log/auth.log on Ubuntu systems. On Windows, the Security event log is where logon events are recorded. Knowing where to look is half the job.
A few events worth memorizing
For the exam and for real life, a handful of Windows Security event IDs come up again and again:
- 4624: a successful logon
- 4625: a failed logon
- 4720: a user account was created
- 4732: a member was added to a security enabled local group
A burst of 4625 events followed by a 4624 from the same source is a classic pattern to investigate. It can mean someone guessed a password. It can also mean a user simply forgot theirs and finally got it right. The log tells you what happened. Context tells you whether it matters.
Baseline first, then look for what is different
CySA+ spends a lot of time on the idea of a baseline, and I think it is the most practical concept in the whole exam. You cannot spot unusual activity until you know what normal looks like. How many failed logins does this server see on a typical day? Which accounts log in after midnight as part of their normal work? Which services restart every night because of a scheduled job?
Once you know normal, the interesting lines jump out on their own. A failed login count that is usually five and is suddenly five hundred does not need a fancy tool to notice.
Reduce before you read
My rule is to shrink the data before I try to understand it. Filter to the event you care about, group by the thing that matters (an account, a source address, an hour of the day), and count. A list of ten addresses with counts is something a person can actually read. Ten thousand raw lines is not.
Here is a small Python script I use to practice this on a Linux authentication log. It counts failed password attempts by source address and prints the top ten:
from collections import Counter
counts = Counter()
with open("auth.log") as f:
for line in f:
if "Failed password" in line:
parts = line.split()
if "from" in parts:
ip = parts[parts.index("from") + 1]
counts[ip] += 1
for ip, n in counts.most_common(10):
print(ip, n)Nothing about this is advanced. That is the point. It turns a wall of text into a short answer to one question, and it takes a minute to write. I run it against practice logs from my home lab, where I can create failed logins on purpose and confirm the script catches them.
Time is your best friend
When something looks off, line it up by time. What happened right before the first failed login? What happened right after the success? Correlating events across sources, such as a firewall log, an authentication log and an application log, is how a single odd line turns into a clear story. Make sure your systems agree on the time, too. If one machine is a few minutes off, your timeline will lie to you.
Write down what you found
The last habit I picked up from studying is writing short notes as I go: what question I asked, what I filtered on, what I found and what I decided. It feels slow at first. It saves a lot of time later, and it is exactly how real incident reports get written.
The short version
Start with a question. Know a few key events. Learn what normal looks like. Filter, group and count before you read. Line things up by time. Write it down.
If you are studying for CySA+, practice these steps on logs you generate yourself. Reading about log analysis helps, but nothing beats watching your own test show up in a file and knowing exactly why it is there.