Understanding Logs : The Backbone of Detection
Every attack leaves a trail. Logs help analysts follow it.
Software engineering learner documenting my journey across Java, backend development, DSA, and cybersecurity. I write beginner-friendly explanations, practical notes, and lessons learned while building and analyzing real-world systems.
Understanding Cybersecurity Step by Step - Part 6
In Part 5, we followed Arjun through his morning shift.
He opened 52 alerts. He triaged them one by one. He asked the same questions every time -
what triggered this, which IP, is this normal, what time did it happen?
But here's what I didn't stop to explain.
Where did all that information come from?
How did Arjun know what IP was involved? How did he know the login happened at 11 PM?
How did he know 340 attempts came from a single source in 4 minutes?
The answer is logs.
Everything Arjun read, every decision he made, every note he wrote - it was all built on logs.
And yet when I first started learning cybersecurity, logs felt like the most boring topic imaginable. Just lines of text. Just timestamps and numbers. Just noise.
That changed completely when I understood what logs actually are.
Let me show you something first
Before any explanation, look at this:
2024-11-12 02:14:33 FAILED LOGIN user: admin IP: 185.220.101.45 attempts: 1
2024-11-12 02:14:34 FAILED LOGIN user: admin IP: 185.220.101.45 attempts: 2
2024-11-12 02:14:34 FAILED LOGIN user: root IP: 185.220.101.45 attempts: 3
2024-11-12 02:14:35 FAILED LOGIN user: admin IP: 185.220.101.45 attempts: 4
...
2024-11-12 02:18:47 FAILED LOGIN user: admin IP: 185.220.101.45 attempts: 340
You didn’t need me to explain anything.
You already know what’s happening here.
That’s what a good log does - it tells a story.
And a SOC analyst’s job is to read that story before it has a bad ending.
That's what a good log does, it tells a story. And a SOC analyst's job is to read that story before it has a bad ending.
So what exactly is a log?
A log is just a record.
Every system - your web server, your firewall, your laptop, your application, automatically writes down what it's doing. Every event. Every connection. Every login attempt. Every file accessed. Every error.
It doesn't decide what's important. It doesn't filter. It just writes everything down, all the time, in order.
Think of it like a CCTV camera that never stops recording.
Most of the footage is useless - people walking past, lights changing, nothing happening. But when something goes wrong, you go back to the recording and suddenly every second matters.
Logs are the CCTV footage of your digital environment.
Why do logs matter so much in security?
Because attackers can’t move without leaving traces.
Every single thing an attacker does creates a log entry somewhere.
They scan your ports? The firewall logs it.
They try to log in? The authentication server logs it.
They run a suspicious command? The endpoint logs it.
They access a file they shouldn't? The file system logs it.
They move to another machine? The network logs it.
The attack itself might be invisible in real time. But the logs are always there, quietly recording everything.
The question isn't whether the attacker left evidence.
The question is whether anyone is reading it.
Not all logs are the same
This is where it gets interesting.
Different systems generate different types of logs. And each type tells a different part of the story.
1. Authentication Logs
These record every login attempt - successful or not.
2024-11-12 09:03:11 LOGIN SUCCESS user: john.doe IP: 103.21.44.12
2024-11-12 09:47:22 LOGIN FAILED user: john.doe IP: 185.220.101.45
2024-11-12 09:47:23 LOGIN FAILED user: john.doe IP: 185.220.101.45
2024-11-12 09:47:24 LOGIN FAILED user: john.doe IP: 185.220.101.45
What this tells you: John logged in successfully from one IP at 9 AM. Then someone from a completely different IP tried to log in as John three times in a row one second apart.
That second IP isn't John. That's an attacker.
Authentication logs are where brute force attacks, credential stuffing, and account takeovers show up first.
2. Network Logs (Firewall Logs)
These record every connection that tried to enter or leave your network - what was allowed, what was blocked, and from where.
2024-11-12 02:10:01 ALLOW src:192.168.1.10 dst:8.8.8.8 port:443
2024-11-12 02:11:15 BLOCK src:185.220.101.45 dst:10.0.0.5 port:22
2024-11-12 02:11:16 BLOCK src:185.220.101.45 dst:10.0.0.5 port:3389
2024-11-12 02:11:17 BLOCK src:185.220.101.45 dst:10.0.0.5 port:80
What this tells you: One IP is trying to connect to the same destination on different ports, one after another. That's a port scan, an attacker mapping what's open before they try to get in.
Firewall logs reveal reconnaissance activity. They show you who's knocking and which doors they're trying.
3. System Logs (Endpoint Logs)
These come from individual machines - laptops, servers, desktops. They record what processes ran, what files were touched, what commands were executed.
2024-11-12 03:22:10 PROCESS STARTED cmd.exe parent:word.exe user:john.doe
2024-11-12 03:22:11 FILE CREATED payload.exe
2024-11-12 03:22:14 NETWORK CONNECT payload.exe dst:45.33.32.156 port:4444
What this tells you: A Word document launched a command prompt. The command prompt created an executable file. That file immediately reached out to an external IP.
This is a classic malware pattern: a phishing document that drops a malicious file and calls home.
System logs are where you see the attacker's actions on the machine - what they ran, what they created, what they stole.
4. Application Logs
These come from the applications themselves - your web server, your database, your API.
2024-11-12 14:05:22 GET /products?id=1 normal request
2024-11-12 14:05:31 GET suspicious SQL payload detected
2024-11-12 14:05:39 GET malicious query attempt detected
What this tells you: Someone is submitting SQL injection payloads through the product search field. The 500 errors mean the database is throwing errors, the attacker is probing for a weakness.
Application logs reveal web attacks - SQL injection, XSS, API abuse, things that happen at the software layer, not the network layer.
Reading logs like an analyst
Here's what most beginners miss.
One log entry by itself tells you almost nothing.
It's the pattern that tells the story.
Look at this again:
2024-11-12 02:11:15 FAILED LOGIN user:admin IP:185.220.101.45
Alone, this means nothing. Maybe someone typed their password wrong.
But zoom out:
02:11:15 FAILED LOGIN user:admin IP:185.220.101.45
02:11:15 FAILED LOGIN user:root IP:185.220.101.45
02:11:16 FAILED LOGIN user:admin IP:185.220.101.45
02:11:16 FAILED LOGIN user:test IP:185.220.101.45
02:11:17 FAILED LOGIN user:admin IP:185.220.101.45
Five different usernames. Same IP. Same second.
That's not a person typing wrong. That's an automated tool running a credential list.
That's a brute force attack.
The analyst's skill is zooming out - taking one entry and asking: what does this look like in the context of everything else?
The problem: there are too many logs
Here's the reality that hit me when I learned this.
A medium-sized company generates millions of log entries every single day.
Millions.
Nobody can read millions of log lines manually. It's impossible.
So how does any of this actually work?
This is exactly why SIEM exists.
The SIEM collects all those logs - from every system, every device, every application into one place. It then runs rules on them automatically. Rules like:
"If the same IP fails to log in more than 100 times in 5 minutes, raise an alert."
"If a process spawned by a Word document makes a network connection, raise an alert."
"If a user logs in from two different countries within 1 hour, raise an alert."
The SIEM reads the millions. It raises the dozens. The analyst reads the dozens.
That's the chain. Logs feed the SIEM. SIEM creates alerts. Analyst investigates alerts.
And every alert the analyst investigates? They go back to the raw logs to verify.
The logs are always the source of truth.
The four things that matter in every log
When I started reading logs, I didn't know where to look. Everything felt equally important or equally meaningless.
But over time I realized - four things give you most of the story.
Timestamp --> When did this happen? Is this 2 AM or business hours? Is this happening every second or once a day? Time changes everything.
Source IP --> Where did this come from? Is it internal or external? Have we seen this IP before? Is it flagged by threat intelligence?
Action --> What actually happened? A successful login? A failed login? A file deletion? A connection to an unknown server?
User or process --> Who or what did this? Is this a real employee? A service account? A process that shouldn't be making network connections?
Those four things: timestamp, source IP, action, user - answer most of the questions an analyst needs to answer.
Everything else is detail.
What changed for me after understanding this
Before I understood logs, SIEM dashboards looked like noise to me. Just numbers and alerts, nothing connecting to anything.
After understanding logs:
I understood why the SIEM fires the alert it fires. It's not magic, it's a rule triggered by a pattern in the raw logs.
I understood why analysts go back to the raw logs even after reading the alert - because the alert summarizes, but the logs tell the full story.
I stopped seeing logs as boring text. Every line is a moment in time. A decision a system made. A connection that was allowed or blocked. A command someone ran.
Together, those moments build a timeline.
And a timeline is how you reconstruct exactly what an attacker did - from the first port scan to the last file they touched.
Key Takeaway
Logs are the evidence.
Everything else - SIEM, alerts, investigations is built on top of them.
Different systems create different logs, and each type reveals a different layer of attacker behaviour. The skill isn't reading one log entry. It's reading the pattern across hundreds of entries and asking:
does this tell a normal story, or does something feel wrong?
👉 In Part 7, we go into how SIEM works step by step - how it collects logs, what rules look like, and how an alert actually gets created from raw data.
Part of the series: Understanding Cybersecurity Step by Step
Part 1: What Really Happens When You “Just Open a Website”?
Part 2: Where Networks Become Vulnerable
Part 3 : How Hackers Find Vulnerabilities
Part 4: What Happens After a Cyber Attack?
Part 5: What Does a SOC Analyst Actually Do?
Part 6: Understanding Logs : The Backbone of Detection (This Blog)
