Logs and Monitoring: Your First Line of Defense

You’ve spent five modules learning how attacks work - the kill chain, reconnaissance, exploitation, privilege escalation, social engineering. Now the question: how do you actually detect any of this?

The answer starts with logs. Every system, application, and network device records what it does. Logs are the forensic evidence, the early warning system, and the audit trail all rolled into one. Without logs, you’re defending blind.

What Are Logs?

A log is a timestamped record of an event. Something happened, and the system wrote it down.

Jan 30 14:23:01 webserver sshd[2847]: Failed password for root from 192.168.1.105 port 44312 ssh2

This single line tells you: when (Jan 30 14:23:01), where (webserver), what service (sshd), what happened (failed password for root), and who tried (192.168.1.105).

One failed login is noise. Five hundred failed logins from the same IP in ten minutes is a brute-force attack. That’s the difference between raw logs and useful intelligence - context and pattern.

Log Types

Operating System Logs

Linux stores logs in /var/log/:

Log File	What It Records
/var/log/auth.log	Authentication events (logins, sudo, SSH)
/var/log/syslog	General system messages
/var/log/kern.log	Kernel messages (hardware, drivers)
/var/log/dpkg.log	Package installations and removals
/var/log/cron.log	Cron job execution
/var/log/lastlog	Last login for each user

# Watch authentication events in real time
tail -f /var/log/auth.log

# Search for failed SSH logins
grep "Failed password" /var/log/auth.log

# See who logged in recently
last -10

Windows uses the Event Log system, viewable through Event Viewer or PowerShell:

Log	What It Records
Security	Logins, logoffs, privilege use, policy changes
System	Service starts/stops, driver issues, hardware events
Application	Application errors, warnings, information
PowerShell	Script execution, command history
Sysmon (if installed)	Process creation, network connections, file changes

# Get recent failed logins (Event ID 4625)
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} -MaxEvents 10

# Get recent successful logins (Event ID 4624)
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624} -MaxEvents 10

Windows Event IDs are critical knowledge for defenders. The most important ones:

Event ID	Meaning
4624	Successful login
4625	Failed login
4648	Login with explicit credentials (runas)
4672	Admin privileges assigned
4688	New process created
4720	User account created
4732	User added to a security group
7045	New service installed

Application Logs

Web servers, databases, and applications all generate logs:

Web server access logs (Apache/Nginx):

192.168.1.50 - - [30/Jan/2026:14:30:15 +0000] "GET /admin/login HTTP/1.1" 200 4523
192.168.1.50 - - [30/Jan/2026:14:30:16 +0000] "POST /admin/login HTTP/1.1" 401 187
192.168.1.50 - - [30/Jan/2026:14:30:16 +0000] "GET /../../etc/passwd HTTP/1.1" 400 0

That third line is a path traversal attempt - someone trying to read system files through the web server. This is the kind of thing log monitoring catches.

Database logs:

• Query logs (who ran what SQL)
• Error logs (failed connections, syntax errors)
• Slow query logs (performance issues, but also potential exfiltration)

Network Logs

Source	What It Records
Firewall	Allowed/denied connections, source/destination IPs
DNS	Domain lookups (useful for detecting C2 communication)
Proxy/WAF	Web requests, blocked attacks, URL filtering
IDS/IPS	Detected attack signatures, anomalies
NetFlow	Connection metadata (who talked to whom, how much data)

Network logs are where you spot lateral movement, data exfiltration, and command-and-control traffic. If a workstation suddenly starts making DNS queries to a3f8x.malware-c2.com every 60 seconds, DNS logs reveal it.

From Logs to Detection: SIEM

Reading individual log files works on a single server. In a real environment with hundreds of systems, you need a SIEM - Security Information and Event Management.

A SIEM does three things:

1. Collects - Gathers logs from all your systems into one place
2. Correlates - Connects related events across systems
3. Alerts - Triggers notifications when patterns match known threats

How Correlation Works

A single event: “User logged in from a new IP.” Not necessarily suspicious.

But combine multiple events:

1. User jsmith failed login 5 times (auth log)
2. User jsmith succeeded on attempt 6 (auth log)
3. User jsmith accessed finance share for first time (file server log)
4. 2GB uploaded to external IP (firewall log)
5. All within 30 minutes, at 3 AM

Individually, each event has an innocent explanation. Together, they tell the story of a compromised account being used for data theft. This is what correlation does - it finds the narrative.

Common SIEM Platforms

Platform	Type	Notes
Splunk	Commercial	Industry standard, powerful but expensive
Microsoft Sentinel	Cloud	Integrates with Azure/M365 ecosystem
Elastic Security	Open source + commercial	Built on Elasticsearch
Wazuh	Open source	Good for learning, runs on your own hardware
QRadar (IBM)	Commercial	Enterprise-focused

If you’re learning, start with Wazuh or Elastic Security. Both are free, well-documented, and used in production environments. Our detection lab guide walks through setting up a monitoring environment.

Detection Rules

A detection rule defines “if you see this pattern, alert me.” Here’s the logic behind common rules:

Brute Force Detection

IF: More than 10 failed logins from the same source IP within 5 minutes
THEN: Alert "Possible brute force attack"

Impossible Travel

IF: User logs in from New York
AND: Same user logs in from Tokyo within 30 minutes
THEN: Alert "Impossible travel - possible credential compromise"

Suspicious Process Execution

IF: PowerShell spawned by Microsoft Word
THEN: Alert "Possible malicious macro execution"

This last one is a classic indicator of the kill chain delivery stage - a phishing document running code.

Reducing False Positives

The biggest challenge in detection isn’t missing attacks - it’s alert fatigue. Too many false positives and analysts stop investigating alerts.

Good detection rules:

• Tune thresholds - Is 10 failed logins the right number? Maybe your environment has a legitimate service that fails 5 times before authenticating
• Whitelist known behavior - If the backup server always connects to the file server at 2 AM, don’t alert on it
• Add context - “Failed login” is noisy. “Failed login to a domain admin account from a workstation that isn’t the admin’s” is specific

What to Monitor First

You can’t monitor everything immediately. Start with the highest-value logs:

1. Authentication events - Failed and successful logins, especially to privileged accounts
2. Account changes - New accounts created, privilege changes, group membership changes
3. Process execution - Unexpected processes, especially PowerShell, cmd.exe spawned by unusual parents
4. Network connections - Outbound connections to unusual destinations, large data transfers
5. Firewall denials - Repeated blocked connections indicate scanning or lateral movement attempts

This covers the majority of attack indicators. You can expand from there.

Try It

On a Linux system you have access to:

# 1. Look at recent auth events
grep -i "session opened\|failed\|accepted" /var/log/auth.log | tail -20

# 2. Count failed SSH logins by IP
grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn

# 3. Check what's being logged to syslog right now
tail -f /var/log/syslog

On Windows:

# 1. Get the last 10 failed logins
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} -MaxEvents 10 |
    Select-Object TimeCreated, Message

# 2. Check for new services installed
Get-WinEvent -FilterHashtable @{LogName='System'; Id=7045} -MaxEvents 5

Even on your personal machine, you’ll find more log data than you expected.

What’s Next

Logs tell you something happened. But what do you do when that something is an active attack? The next post covers incident response - the structured process for containing, investigating, and recovering from security incidents.

References

• MITRE ATT&CK - Data Sources
• Windows Security Event Log Encyclopedia
• Wazuh Documentation
• Sigma Rules - Open source detection rule format

---

The best security tools in the world are useless if nobody’s watching the output. Logs are cheap. Ignoring them is expensive.