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
| Detail | Value |
|---|---|
| Lab Profile | lab-wazuh |
| Containers | Wazuh Manager, Wazuh Indexer, Wazuh Dashboard, Wazuh Agent |
| Estimated Time | 45–60 minutes |
| Difficulty | Beginner |
| Browser Access | Web UI — opens directly in your browser |
| Pre-Loaded Data | 500+ events spanning 10 distinct log sources |
| Deliverable | Completed 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:
| Agent | Hostname | IP | Role |
|---|---|---|---|
| 001 | linux-web-01 | 10.0.2.15 | Linux web server (Apache, SSH) |
| 002 | WIN-SERVER-01 | 10.0.2.20 | Windows domain server |
| 003 | dns-server-01 | 10.0.2.10 | Internal DNS resolver |
| 004 | fw-edge-01 | 10.0.1.1 | Edge 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.
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:
| Field | What It Tells You |
|---|---|
logonType | 2 = Interactive (keyboard), 3 = Network (SMB/RPC), 5 = Service, 7 = Unlock, 10 = Remote Desktop |
targetUserName | Who logged in |
ipAddress | Where they came from (- means local) |
processName | What 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:
| Field | What It Tells You |
|---|---|
targetUserName | Account being targeted |
ipAddress | Attacker's source IP |
failureReason | Why it failed (bad password vs. nonexistent account) |
subStatus | 0xc000006a = 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.
| Field | What It Tells You |
|---|---|
newProcessName | Full path of the new process |
parentProcessName | What launched it (critical for attack chain analysis) |
subjectUserName | Who started the process |
processCommandLine | The 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.
| Field | What It Tells You |
|---|---|
serviceName | Name of the new service |
imagePath | Path to the executable |
startType | auto start = runs on boot (persistence!), demand start = manual |
accountName | Which 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 Type | Rule IDs | What It Tells You |
|---|---|---|
| Successful login | 5501 | Who logged in, from where, key vs. password |
| Failed login | 5503 | Wrong password for valid user |
| Invalid user | 5710 | Attacker trying nonexistent usernames |
| Brute force | 5551 | Threshold 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 Type | Rule IDs | What It Tells You |
|---|---|---|
| First-time sudo | 5401 | User executing sudo for the first time |
| Sudo to root | 5402 | Successful 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.
| Field | What It Tells You |
|---|---|
url (domain) | What domain was queried |
srcip | Which 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.
| Field | What It Tells You |
|---|---|
srcip | Who tried to connect |
dstip | What internal system they targeted |
dstport | What service they tried to reach |
protocol | TCP or UDP |
action | drop (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:
| Event | Rule ID | What It Tells You |
|---|---|---|
| File modified | 550 | Checksum changed — config file tampered? |
| File added | 554 | New file appeared — malware drop? |
| File deleted | 553 | File 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
Step 11: Complete the Reference Sheet
For each of the 10 log sources, fill in this table based on what you observed:
| # | Log Source | Agent | Location / Event ID | What It Tells You | Example Event You Found | ATT&CK Techniques It Detects |
|---|---|---|---|---|---|---|
| 1 | Windows Logon Success | WIN-SERVER-01 | Security / 4624 | |||
| 2 | Windows Logon Failure | WIN-SERVER-01 | Security / 4625 | |||
| 3 | Process Creation | WIN-SERVER-01 | Security / 4688 | |||
| 4 | New Service Installed | WIN-SERVER-01 | System / 7045 | |||
| 5 | SSH Authentication | linux-web-01 | /var/log/auth.log | |||
| 6 | Sudo / Privilege | linux-web-01 | /var/log/auth.log | |||
| 7 | DNS Queries | dns-server-01 | /var/log/named/ | |||
| 8 | Firewall Blocks | fw-edge-01 | /var/log/firewall | |||
| 9 | Agent Heartbeat | All agents | ossec | |||
| 10 | File Integrity (FIM) | linux-web-01, WIN-SERVER-01 | syscheck |
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:
- Which log sources gave you the most security-relevant events? Rank your top 3 by detection value.
- Which agent had the most suspicious activity? Why?
- 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).
- 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
Navigate to the Agents tab in Wazuh. How many agents are reporting to this instance, and what are their names?
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?
Find DNS query events from dns-server-01. The Windows server (10.0.2.20) made a DNS query — what domain did it resolve?
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?
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?
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?
What is the IP address of the dns-server-01 agent as shown in the Agents tab?
The lab mentions that in Windows 4625 (failed logon) events, the subStatus code 0xc000006a has a specific meaning. What does it indicate?
How many distinct log source types does this lab environment contain? Count each unique category from the lab instructions.
In the firewall logs, you can identify port scanning behavior. Which pattern indicates a port scan according to the lab instructions?
0/10 answered