Log Sources That Matter

Why Log Sources Are Everything

In Module 1, you learned that a SIEM is the central nervous system of the SOC. But a SIEM is only as good as the data flowing into it. If a log source isn't connected, the SIEM can't see it — and neither can you. Every blind spot in your log coverage is an opportunity for an attacker to operate undetected.

In Lab 1.3, you explored 10 log sources inside Wazuh and built a Log Source Reference Sheet. Now we're going to expand that foundation. A real enterprise SOC doesn't monitor 10 sources — it monitors hundreds, organized into 8 major categories. Understanding these categories is what separates a junior analyst who reacts to alerts from a senior analyst who understands the full picture.

The #1 question every SOC analyst should ask on day one: "What log sources do we have — and what are we missing?"

Click to enlarge

Category 1: Windows Event Logs

Windows Event Logs are the single most important log source in most enterprise SOCs because the vast majority of corporate endpoints and servers run Windows. The Windows Security channel alone generates the events you'll spend 60-70% of your time investigating.

Click to enlarge

The Must-Know Event IDs

Logon Types — The Context That Changes Everything

When you see Event ID 4624 or 4625, the logon type field tells you how the authentication happened. This single field can mean the difference between a routine event and an active intrusion:

What Windows Event Logs Don't Tell You

Windows Security logs are powerful, but they have blind spots:

• No command-line arguments in 4688 unless you enable "Include command line in process creation events" via Group Policy
• No DLL loading, registry changes, or network connections per process — that's what Sysmon adds (Lesson 2.6)
• No file content analysis — you know a file was created but not what's in it (that's YARA, Module 7)

Category 2: Linux / Syslog

Linux systems generate logs through the syslog facility and dedicated log files. In a SOC, you'll encounter Linux logs from web servers, DNS servers, database servers, network appliances, and cloud instances.

The Critical Log Files

Reading auth.log — What Matters

A single SSH brute force attempt in auth.log looks like this:

Feb 15 06:15:02 linux-web-01 sshd[5102]: Invalid user admin from 185.220.101.42 port 44891
Feb 15 06:15:14 linux-web-01 sshd[5104]: Failed password for root from 185.220.101.42 port 44903

The fields that matter for triage:

• Timestamp — when did it happen?
• Hostname — which server was targeted?
• Program — sshd, sudo, cron, etc.
• Source IP — internal (expected) or external (investigate)?
• Username — valid user or random guess?

Linux Audit Framework (auditd)

When auditd is enabled, it provides the deepest Linux visibility — comparable to what Sysmon gives on Windows. It can log:

• Every process execution with full command lines
• File access and permission changes
• Network socket creation
• System calls

Most production Linux servers in security-conscious organizations run auditd. If you see /var/log/audit/audit.log events in your SIEM, you have premium Linux visibility.

Category 3: Firewall & Network Device Logs

Firewalls sit at network boundaries and log every connection they allow or block. They're your perimeter visibility — the first and last line of defense.

What Firewall Logs Contain

Common Firewall Platforms You'll Encounter

What to Look For

• Repeated drops to the same port from one IP — port scanning (reconnaissance)
• Drops on port 4444, 5555, or other non-standard ports — reverse shell attempts
• Allowed connections to known-bad IPs — C2 communication that got through
• Large outbound data transfers — potential exfiltration
• Internal-to-internal drops — misconfiguration or lateral movement attempts

Category 4: DNS Query Logs

Every network connection starts with a DNS query. Before malware can call home to evil-c2.example.com, it has to resolve that domain to an IP address. DNS logs capture every one of these queries.

Why DNS Logs Are a SOC Goldmine

1. C2 Detection — Malware must resolve its C2 domain. DNS logs record it even if the actual C2 traffic is encrypted.
2. DNS Tunneling — Attackers encode data inside DNS queries to exfiltrate information. These show up as unusually long subdomains or high query volumes to a single domain.
3. DGA Detection — Domain Generation Algorithms produce random-looking domains (xk7gf2p9.net). A spike in queries to newly-registered or algorithmically-generated domains is a strong malware indicator.
4. Shadow IT Discovery — DNS logs reveal what cloud services employees are using (Dropbox, personal email, unauthorized SaaS).

What DNS Log Fields Matter

Suspicious DNS Patterns

Category 5: Web Proxy / HTTP Logs

A web proxy (also called a Secure Web Gateway) sits between users and the internet. It inspects, logs, and optionally blocks web traffic. In organizations that route all web traffic through a proxy, these logs are a treasure trove.

What Proxy Logs Capture

SOC Use Cases

• Malware delivery detection — User visited a compromised website, proxy logged the URL and the .exe download
• C2 callback identification — Infected host makes periodic HTTPS connections to cdn-static-assets.xyz every 60 seconds
• Data exfiltration — Large POST requests to an uncategorized domain at 3 AM
• Policy violation — Employee accessing unauthorized file-sharing or personal cloud storage
• Phishing follow-through — After clicking a link in email, what did they actually browse to?

Common Proxy Platforms

Category 6: Email Gateway Logs

Phishing remains the #1 initial access vector in real-world attacks. In Lab 1.2, the APT29 scenario started with spearphishing emails (T1566.001). Email gateway logs are where you detect and investigate these attacks.

What Email Gateway Logs Capture

Why Email Logs Are Critical for Investigation

When a phishing campaign hits your organization, the SIEM alert might only show one user who clicked. Email gateway logs answer the harder questions:

1. How many people received the same email? (scope of the campaign)
2. Did anyone else click the link or open the attachment? (other potential victims)
3. Was the email quarantined or delivered? (do you need to pull it from mailboxes?)
4. What was the sender domain and IP? (IOCs for threat intel — Module 5)

Common Email Security Platforms

Category 7: Cloud Audit Trails

Modern organizations run hybrid environments — on-premises servers plus cloud infrastructure (AWS, Azure, GCP) plus SaaS applications (M365, Salesforce, Slack). Each of these generates audit logs that track who did what.

The Big Three Cloud Audit Sources

Why Cloud Logs Matter More Every Year

• Identity is the new perimeter. In cloud environments, there's no firewall between the attacker and your data — just an identity (username + password + MFA). Cloud audit logs track every authentication and authorization decision.
• Attackers target cloud directly. Credential stuffing against Azure AD, phishing for M365 tokens, compromising AWS access keys — these attacks skip your on-prem defenses entirely.
• Data lives in the cloud. If an attacker exfiltrates data from SharePoint or S3, the only log that records it is the cloud audit trail.

Key Cloud Events to Monitor

Category 8: Application & Database Logs

Every application generates logs — web servers, databases, custom business applications, middleware. These logs are often overlooked in SOCs but contain evidence that no other source captures.

Web Server Logs

Web server logs detect:

• SQL injection attempts — /api/users?id=1' OR '1'='1 (T1190)
• Web shell access — Repeated requests to /uploads/shell.php from a single IP
• Directory traversal — /../../etc/passwd in URL paths
• Vulnerability scanning — Rapid requests to known vulnerable paths (/wp-login.php, /phpmyadmin, /.env)

Database Audit Logs

Database audit logs detect:

• Unauthorized data access — SELECT queries on sensitive tables from unusual users
• Data manipulation — UPDATE/DELETE on critical records
• Schema changes — DROP TABLE, ALTER TABLE from non-admin accounts
• Privilege escalation — GRANT commands giving excessive permissions

Custom Application Logs

Many organizations build custom applications that generate their own logs. These often contain business-context that no other log source provides:

• Authentication events specific to the application
• Business logic violations (e.g., transferring more than a threshold amount)
• API access patterns that indicate scraping or abuse

Connecting Log Sources to ATT&CK

In Lab 1.2, you mapped 15 APT29 techniques to the ATT&CK framework and color-coded them by detection capability. Now let's see which log sources cover which tactics:

Click to enlarge

The Log Source Priority Matrix

Not every log source is equally important. If you're building a SOC from scratch or evaluating coverage, here's how to prioritize:

What Happens When a Log Source Is Missing

Practical Application: Your Lab Environment

In Lab 1.3, you worked with events from 4 agents covering 10 log sources. Here's how they map to the 8 categories you just learned:

The gaps are intentional — email gateway and cloud audit logs require enterprise infrastructure that doesn't fit in a lab container. But now you know they exist and what they provide, so when you encounter them in a real SOC, you'll understand their value immediately.

What's Next

You now understand what data flows into a SIEM. In Lesson 2.2 — Anatomy of a SIEM Alert, you'll learn what happens after the data arrives: how Wazuh rules turn raw log events into the alerts you investigate, and how to read every field in an alert quickly and accurately.