Hands-on LabBeginner·~55 min·Includes challenge

Lab 1.3 — Know Your Logs

Explore 500+ events across 10 log sources in Wazuh. Build a Log Source Reference Sheet.

Tools needed:Wazuh Dashboard

What You'll Learn

  • Identify and navigate 10 distinct log sources inside the Wazuh Dashboard
  • Understand what each log source tells you and when it matters for detection
  • Filter events by log source, agent, rule group, and severity level
  • Connect log sources to the ATT&CK techniques you mapped in Lab 1.2
  • Complete a Log Source Reference Sheet documenting every source

Lab Overview

DetailValue
Lab Profilelab-wazuh
ContainersWazuh Manager, Wazuh Indexer, Wazuh Dashboard, Wazuh Agent
Estimated Time45–60 minutes
DifficultyBeginner
Browser AccessWeb UI — opens directly in your browser
Pre-Loaded Data500+ events spanning 10 distinct log sources
DeliverableCompleted Log Source Reference Sheet

Building Your Foundation. In Lab 1.1, you traced 3 alerts through the pipeline. In Lab 1.2, you mapped detection gaps. Now you're going to answer the fundamental question every SOC analyst must understand: "What data do we actually have?" Before you can detect anything, you need to know what logs are flowing into your SIEM and what each one can tell you.


Part 1: Explore the Event Landscape

When you click Start Lab, a Wazuh environment will spin up with 500+ pre-loaded events from 4 agents representing a small enterprise network: a Linux web server, a Windows domain server, a DNS server, and an edge firewall.

Step 1: Log In and Open Security Events

Click the lab link to open the Wazuh Dashboard.

Credentials:

  • Username: admin
  • Password: SecretPassword

Navigate to Modules → Security Events. You should see hundreds of events. Set the time range to Last 24 hours (or wider) to ensure you see all pre-loaded data.

Step 2: Survey the Agents

Click the Agents tab in the top navigation. You should see 4 agents reporting:

AgentHostnameIPRole
001linux-web-0110.0.2.15Linux web server (Apache, SSH)
002WIN-SERVER-0110.0.2.20Windows domain server
003dns-server-0110.0.2.10Internal DNS resolver
004fw-edge-0110.0.1.1Edge firewall (iptables)
💡

Real SOC Parallel. In a production SOC, your first day task is often "learn what agents we have." Every missing agent is a blind spot. If an endpoint isn't sending logs, you can't detect attacks on it — period.


Part 2: Identify All 10 Log Sources

Your lab environment contains events from 10 distinct log sources. Your job is to find each one, understand what it tells you, and document it.

10 Log Sources in Your SOC

The 10 Log Sources

Use the search bar and filters in Security Events to find events from each source. For each one, find at least 2-3 example events and study them.

Step 3: Windows Authentication — Event IDs 4624 & 4625

Filter by agent WIN-SERVER-01 and look for events with eventID: 4624 (successful logon) and eventID: 4625 (failed logon).

What to look for in 4624 events:

FieldWhat It Tells You
logonType2 = Interactive (keyboard), 3 = Network (SMB/RPC), 5 = Service, 7 = Unlock, 10 = Remote Desktop
targetUserNameWho logged in
ipAddressWhere they came from (- means local)
processNameWhat process initiated the logon

Find examples of logon types 2, 3, 5, and 10. Notice how they tell very different stories:

  • Type 5 (Service) = automated, normal
  • Type 10 (RemoteDesktop) = human, investigate if unexpected
  • Type 3 (Network) from an external IP = suspicious

What to look for in 4625 events:

FieldWhat It Tells You
targetUserNameAccount being targeted
ipAddressAttacker's source IP
failureReasonWhy it failed (bad password vs. nonexistent account)
subStatus0xc000006a = wrong password, 0xc0000064 = no such user

The subStatus Code Matters. 0xc000006a (wrong password) means the attacker knows a valid username — they're closer to getting in. 0xc0000064 (no such user) means they're still guessing usernames. This distinction drives investigation priority.

Step 4: Windows Process Creation — Event ID 4688

Filter for eventID: 4688. These events log every new process on the Windows server.

FieldWhat It Tells You
newProcessNameFull path of the new process
parentProcessNameWhat launched it (critical for attack chain analysis)
subjectUserNameWho started the process
processCommandLineThe command line used (if audit policy enables it)

Find examples of:

  • Normal system processes (svchost.exe, services.exe)
  • User applications (chrome.exe, WINWORD.EXE)
  • Suspicious processes (check for executables in \Temp\, \ProgramData\, or \Users\Public\)

Why 4688 Is Gold. Process creation logs are the single most valuable Windows log source for detecting attacks. If an attacker runs mimikatz.exe, psexec.exe, or powershell.exe -enc <base64>, Event ID 4688 records it. Without this log source, you're blind to execution.

Step 5: Windows New Service — Event ID 7045

Filter for eventID: 7045. These fire when a new Windows service is installed.

FieldWhat It Tells You
serviceNameName of the new service
imagePathPath to the executable
startTypeauto start = runs on boot (persistence!), demand start = manual
accountNameWhich account the service runs as

Look for services running from unusual paths (\Temp\, \ProgramData\) or with generic names designed to blend in (WindowsUpdateHelper, SysHealthMonitor).

Step 6: SSH Authentication — /var/log/auth.log

Filter by agent linux-web-01 and look for SSH events (rule groups containing sshd).

Event TypeRule IDsWhat It Tells You
Successful login5501Who logged in, from where, key vs. password
Failed login5503Wrong password for valid user
Invalid user5710Attacker trying nonexistent usernames
Brute force5551Threshold crossed — active attack

Compare the srcip field: internal IPs (10.0.x.x) are expected, external IPs (185.x.x.x) are suspicious.

Step 7: Sudo and Privilege Escalation

Stay on linux-web-01 and filter for rule group sudo.

Event TypeRule IDsWhat It Tells You
First-time sudo5401User executing sudo for the first time
Sudo to root5402Successful root privilege escalation

Study the full_log field — it contains exactly what command was run as root. Look for:

  • Normal admin work: apt update, systemctl restart
  • Suspicious activity: cat /etc/shadow, bash -c '...', commands in /tmp/
🚨

www-data Running Sudo? If you see the web server user (www-data) executing commands via sudo, that's a red flag. Web applications should never need root access. This pattern indicates web shell exploitation or application compromise.

Step 8: DNS Queries

Filter by agent dns-server-01 (agent 003) or rule group dns.

FieldWhat It Tells You
url (domain)What domain was queried
srcipWhich internal host made the query
id (query type)A, AAAA, MX, TXT, CNAME

Sort through the queries and separate them into categories:

  • Normal: windowsupdate.microsoft.com, github.com, time.google.com
  • Suspicious: Domains with unusual TLDs (.xyz, .cc, .io for non-tech companies), very long subdomains (DNS tunneling indicator), domains containing random strings
💡

DNS Never Lies. Every network connection starts with a DNS query. If malware calls home to evil-c2.example.com, the DNS log records it — even if the actual C2 traffic is encrypted. This makes DNS logs one of the most reliable sources for detecting C2 communication.

Step 9: Firewall Blocks

Filter by agent fw-edge-01 (agent 004) or rule group firewall_drop.

FieldWhat It Tells You
srcipWho tried to connect
dstipWhat internal system they targeted
dstportWhat service they tried to reach
protocolTCP or UDP
actiondrop (blocked by policy)

Look for patterns:

  • Same source IP hitting multiple ports = port scan
  • Hits on port 22, 3389, 445 = remote access attempts
  • Hits on port 4444, 5900 = reverse shell / VNC (high priority)

Step 10: Agent Heartbeat and File Integrity Monitoring

Agent Heartbeat (rule 530): Filter for rule ID 530. These confirm which agents are alive and reporting. If heartbeats stop, the agent may be down — or an attacker may have disabled it.

File Integrity Monitoring (FIM): Filter for rule group syscheck. Three event types:

EventRule IDWhat It Tells You
File modified550Checksum changed — config file tampered?
File added554New file appeared — malware drop?
File deleted553File removed — evidence destruction?

Pay special attention to: /etc/passwd, /etc/shadow, /etc/sudoers (Linux), hosts file, and anything in /tmp/ or web directories.


Part 3: Build Your Log Source Reference Sheet

Log Source Reference Sheet — What Each Log Tells You

Step 11: Complete the Reference Sheet

For each of the 10 log sources, fill in this table based on what you observed:

#Log SourceAgentLocation / Event IDWhat It Tells YouExample Event You FoundATT&CK Techniques It Detects
1Windows Logon SuccessWIN-SERVER-01Security / 4624
2Windows Logon FailureWIN-SERVER-01Security / 4625
3Process CreationWIN-SERVER-01Security / 4688
4New Service InstalledWIN-SERVER-01System / 7045
5SSH Authenticationlinux-web-01/var/log/auth.log
6Sudo / Privilegelinux-web-01/var/log/auth.log
7DNS Queriesdns-server-01/var/log/named/
8Firewall Blocksfw-edge-01/var/log/firewall
9Agent HeartbeatAll agentsossec
10File Integrity (FIM)linux-web-01, WIN-SERVER-01syscheck
💡

ATT&CK Column. Use your work from Lab 1.2 to fill in the last column. For example, Windows 4625 detects T1110 (Brute Force), FIM detects T1565 (Data Manipulation), and DNS queries can reveal T1071.004 (DNS C2). This creates a direct link between your log sources and your detection coverage.

Step 12: Identify the Gaps

After completing your reference sheet, answer these questions:

  1. Which log sources gave you the most security-relevant events? Rank your top 3 by detection value.
  2. Which agent had the most suspicious activity? Why?
  3. What log sources are missing? Think about what a real enterprise would have that this lab doesn't (hint: endpoint telemetry like Sysmon, email logs, proxy logs, cloud audit trails).
  4. If you could only keep 3 log sources, which 3 would you choose and why?

Deliverables Checklist

Before marking this lab complete, verify you have:

  • Log Source Reference Sheet — All 10 rows completed with descriptions, examples, and ATT&CK mappings
  • Filter Proficiency — You can filter by agent, rule group, event ID, and severity in the Wazuh Dashboard
  • Gap Analysis — You answered the 4 gap analysis questions
  • ATT&CK Connection — Each log source is linked to at least one ATT&CK technique from Lab 1.2

Key Takeaways

  • A SIEM is only as good as the log sources feeding it — no logs, no detection
  • Windows Event IDs 4624, 4625, 4688, and 7045 are the four most critical Windows log sources for security monitoring
  • SSH auth logs and sudo logs reveal remote access and privilege escalation on Linux systems
  • DNS logs are one of the most reliable sources for detecting C2 communication because every connection starts with a query
  • Firewall logs show what was blocked — the attacks that didn't get through (but tell you who's trying)
  • File Integrity Monitoring catches the artifacts attackers leave behind: modified configs, dropped files, deleted evidence

What's Next

You've completed Module 1 — The SOC: Your War Room. You can now trace alerts (Lab 1.1), map detection coverage (Lab 1.2), and catalog your data sources (Lab 1.3). In Module 2 — SIEM Mastery, you'll go deeper into Wazuh: building custom dashboards, writing search queries, understanding correlation rules, and learning how Wazuh turns raw logs into the alerts you've been investigating.

Lab Challenge: Know Your Logs

10 questions · 70% to pass

1

Navigate to the Agents tab in Wazuh. How many agents are reporting to this instance, and what are their names?

2

Filter for firewall drop events from fw-edge-01. Find the event where source IP 104.248.100.12 was blocked. What destination port was the attacker targeting?

3

Find DNS query events from dns-server-01. The Windows server (10.0.2.20) made a DNS query — what domain did it resolve?

4

Filter for Windows Event ID 7045 (new service installed) on WIN-SERVER-01. Which service runs from C:\Windows\Temp\ — a highly suspicious path for a service executable?

5

Check the File Integrity Monitoring (syscheck) alerts. Both /etc/passwd and another critical file were modified on linux-web-01. What is the second file?

6

In the Windows 4624 (logon success) events, you observed Logon Type 5 for the svc-backup account. The lab also mentions Type 10. What does Logon Type 10 represent?

7

What is the IP address of the dns-server-01 agent as shown in the Agents tab?

8

The lab mentions that in Windows 4625 (failed logon) events, the subStatus code 0xc000006a has a specific meaning. What does it indicate?

9

How many distinct log source types does this lab environment contain? Count each unique category from the lab instructions.

10

In the firewall logs, you can identify port scanning behavior. Which pattern indicates a port scan according to the lab instructions?

0/10 answered