What You'll Learn
- Investigate phishing-triggered alerts in Wazuh Dashboard using targeted search queries
- Trace the full attack chain from initial email delivery through process execution, network callbacks, and lateral movement
- Identify affected user accounts and systems by correlating alerts across multiple log sources
- Execute containment and response steps including IOC blocking, account isolation, and endpoint quarantine
- Build a timeline of attacker activity using SIEM alert timestamps and event correlation
Lab Overview
| Detail | Value |
|---|---|
| Lab Profile | lab-wazuh |
| Containers | Wazuh Manager, Wazuh Indexer, Wazuh Dashboard |
| Estimated Time | 65–75 minutes |
| Difficulty | Advanced |
| Browser Access | Wazuh Dashboard (Web UI) |
| Pre-Loaded Data | 505 alerts across 10 log sources, 4 agents |
| Deliverable | Phishing incident response report with timeline, affected systems, and containment actions |
From Artifacts to Alerts. In Labs PH.1–PH.4, you analyzed phishing emails as standalone artifacts — headers, authentication records, classifications, and IOCs. Now you're inside the SIEM, investigating what happened AFTER a user clicked a phishing link. This is where phishing analysis meets incident response: finding the downstream damage in your alert data.
The Scenario
Your SOC received an alert: the endpoint agent on linux-web-01 detected a suspicious process execution. Initial triage suggests it originated from a phishing email that an employee clicked. Your job is to use Wazuh to investigate the full incident — find the initial compromise, trace the attack chain, identify all affected systems, and execute the response playbook.
The pre-loaded alert data in your lab environment contains evidence of the entire attack chain. You need to find it.
Part 1: Initial Alert Triage
Start Your Lab
Click Start Lab to launch your Wazuh environment. Once the dashboard loads, navigate to Security Events (Modules → Security Events).
Find the Entry Point
The phishing email contained a malicious link that led to a reverse shell. Start by searching for the initial process execution:
rule.id: 100002
This rule detects suspicious command execution. Document what you find:
INITIAL ALERT TRIAGE
═════════════════════
Alert Rule: 100002
Description: [from rule.description field]
Agent: [agent.name]
Timestamp: [timestamp]
Full Log: [copy the full_log field]
Severity Level: [rule.level]
Decode the Payload
The alert's full_log field contains a base64-encoded command. Look for the base64 string and decode it mentally or note the pattern:
- What type of payload is it? (reverse shell, downloader, etc.)
- What IP and port does it connect to?
- What protocol does it use?
Recognizing Base64 Payloads. Base64-encoded commands in process execution alerts are a critical red flag. Attackers encode payloads to evade simple string-matching detection rules. The pattern bash -c 'echo [base64] | base64 -d | bash' is one of the most common Linux post-exploitation techniques. The Wazuh rule 100002 is specifically designed to catch this pattern.
Part 2: Trace the Attack Chain
Now work backward and forward from the initial alert to build the complete picture.
Step 2A: Find the Brute Force Precursor
The attacker likely gained initial access before executing the payload. Search for authentication attacks:
agent.name: linux-web-01 AND rule.groups: authentication_failed
Document:
- How many failed authentication attempts?
- What source IP(s) are involved?
- What usernames were targeted?
- What is the timeframe of the brute force?
Step 2B: Find SSH Brute Force Specifically
rule.id: 5551 OR rule.id: 5712
Document:
- Rule 5551 = individual SSH auth failure, Rule 5712 = SSH brute force threshold
- How many failures before the brute force rule triggered?
- What IP address performed the brute force?
Step 2C: Look for Successful Access After Brute Force
agent.name: WIN-SERVER-01 AND rule.id: 60106
This rule detects a successful logon after multiple failures (a key post-brute-force indicator):
Document:
- Was there a successful login from the same attacker IP range?
- What account was compromised?
- What is the time gap between the last failure and the success?
Part 3: Identify Lateral Movement
After initial access, attackers move through the network. Search for indicators of lateral movement and privilege escalation.
Step 3A: Sudo Privilege Escalation
data.srcuser: www-data AND rule.groups: sudo
The www-data user is the web server service account. If it's running sudo commands, the attacker has pivoted from the web application to the operating system.
Document each sudo event:
- Command 1: __________ (purpose: __________)
- Command 2: __________ (purpose: __________)
- Command 3: __________ (purpose: __________)
Step 3B: Windows Lateral Movement
agent.name: WIN-SERVER-01 AND rule.id: 18152
Rule 18152 detects Windows brute force attempts. Check if the attacker moved from Linux to Windows:
Document:
- Is the source IP internal (10.x.x.x) or the same attacker IP?
- How many failed logon attempts on the Windows server?
- What accounts were targeted?
Step 3C: New Service Installation
rule.id: 60108
This rule detects new Windows services being installed — a persistence mechanism:
Document:
- Was a new service installed on WIN-SERVER-01?
- What is the service name?
- When was it installed relative to the brute force?
Part 4: Identify All Affected Systems
Build a complete picture of affected assets using agent-specific queries.
Query Each Agent
Run these queries and document the alert count and highest severity for each:
agent.name: linux-web-01 AND rule.level: >= 8
agent.name: WIN-SERVER-01 AND rule.level: >= 8
agent.name: dns-server-01 AND rule.level: >= 8
agent.name: fw-edge-01 AND rule.level: >= 8
AFFECTED SYSTEMS MATRIX
════════════════════════
Agent Alert Count (≥8) Highest Level Key Findings
linux-web-01 [count] [level] [summary]
WIN-SERVER-01 [count] [level] [summary]
dns-server-01 [count] [level] [summary]
fw-edge-01 [count] [level] [summary]
Identify Affected Users
Search for all unique user accounts involved in the incident:
NOT rule.level: 3 AND (data.srcuser: * OR data.win.eventdata.targetUserName: *)
Document every username that appears in non-informational alerts.
Part 5: Execute Response Steps
Based on your investigation, execute (document) the following response actions:
5A: Block Attacker IOCs
List every IP address, domain, and hash that should be blocked:
CONTAINMENT — IOC BLOCKLIST
════════════════════════════
Type IOC Block At Priority
IP [attacker IP 1] Firewall + SIEM CRITICAL
IP [attacker IP 2] Firewall + SIEM HIGH
Domain [C2 domain] DNS + Proxy CRITICAL
Hash [payload hash] EDR HIGH
5B: Account Actions
For each compromised or targeted account, specify the action:
CONTAINMENT — ACCOUNT ACTIONS
══════════════════════════════
Account System Action Status
www-data linux-web-01 Disable + audit commands [Done/Pending]
Administrator WIN-SERVER-01 Force password reset [Done/Pending]
[others] [system] [action] [status]
5C: Endpoint Quarantine
Determine which endpoints need quarantine:
CONTAINMENT — ENDPOINT ACTIONS
═══════════════════════════════
Endpoint Quarantine? Reason Priority
linux-web-01 [Yes/No] [reverse shell + sudo abuse] CRITICAL
WIN-SERVER-01 [Yes/No] [brute force + new service] HIGH
dns-server-01 [Yes/No] [suspicious queries?] MEDIUM
fw-edge-01 [Yes/No] [blocked traffic only?] LOW
Containment Before Eradication. Never skip containment to jump to cleanup. If you start removing malware before blocking the attacker's C2 and isolating compromised systems, the attacker can re-establish access through backup channels. The order is always: Identify → Contain → Eradicate → Recover → Lessons Learned.
Part 6: Build the Incident Timeline
Using the timestamps from your Wazuh queries, construct a chronological timeline of the entire attack:
PHISHING INCIDENT TIMELINE
═══════════════════════════
Time Event Source Alert Agent
[timestamp] SSH brute force begins rule.id: 5551 linux-web-01
[timestamp] Brute force threshold triggered rule.id: 5712 linux-web-01
[timestamp] Suspicious command execution (shell) rule.id: 100002 linux-web-01
[timestamp] Sudo: id command (recon) rule.groups: sudo linux-web-01
[timestamp] Sudo: cat /etc/shadow (cred theft) rule.groups: sudo linux-web-01
[timestamp] Sudo: /bin/bash (full root shell) rule.groups: sudo linux-web-01
[timestamp] Windows brute force detected rule.id: 18152 WIN-SERVER-01
[timestamp] Successful logon after failures rule.id: 60106 WIN-SERVER-01
[timestamp] New service installed (persistence) rule.id: 60108 WIN-SERVER-01
[timestamp] DNS queries to C2 domain [rule.id] dns-server-01
[timestamp] Firewall blocks outbound C2 [rule.id] fw-edge-01
Deliverable Checklist
Before completing the lab, ensure you have:
- Initial Alert Documented — Rule 100002 details with decoded payload
- Attack Chain Traced — Brute force → access → escalation → lateral movement
- Affected Systems Matrix — All 4 agents assessed with alert counts and findings
- IOC Blocklist — All attacker IPs, domains, and hashes listed with blocking actions
- Account & Endpoint Actions — Specific containment steps for each compromised asset
- Incident Timeline — Chronological event sequence with timestamps and source alerts
Key Takeaways
- Phishing investigation in a SIEM starts with the endpoint alert and works outward — finding the initial delivery, lateral movement, and persistence
- Correlating alerts across multiple agents reveals the full attack scope — a single-agent view misses lateral movement
- The attack chain pattern (brute force → access → escalation → lateral movement → persistence) is one of the most common in real incidents
- Containment must happen before eradication — block C2, isolate endpoints, disable accounts before cleaning up
- A timeline built from SIEM timestamps is the foundation of every incident report and post-incident review
What's Next
In Lab PH.6 — Write the Phishing Report, you'll compile all your findings from Labs PH.1–PH.5 into a formal phishing incident report. You'll use a professional template to document the executive summary, timeline, IOCs, affected systems, containment actions, and lessons learned.
Lab Challenge: Phishing Response
10 questions · 70% to pass
You search for 'rule.id: 100002' in Wazuh and find a suspicious command execution alert on linux-web-01. What type of payload does this alert typically indicate?
After finding the initial reverse shell alert, you search for 'rule.id: 5551 OR rule.id: 5712'. What do these rules detect and how do they relate to the phishing incident?
The query 'data.srcuser: www-data AND rule.groups: sudo' returns 3 events. What does www-data running sudo commands indicate?
Rule 60106 on WIN-SERVER-01 detects a successful logon after multiple failures. Why is this alert critical in the context of this phishing investigation?
You need to identify all affected systems. Which query approach gives you the most comprehensive view of the incident scope?
Rule 60108 detects a new Windows service installation on WIN-SERVER-01. Why is this significant in the attack chain?
Your containment plan includes blocking attacker IPs at the firewall. Which IP(s) should be blocked based on the lab's pre-loaded alert data?
Why must containment (blocking IOCs, isolating endpoints) happen BEFORE eradication (removing malware, resetting passwords)?
When building the incident timeline, you notice the reverse shell (rule 100002) occurred AFTER the SSH brute force (rules 5551/5712). What does this sequence reveal about the attacker's methodology?
Your incident investigation is complete. Which of the following should be included in the 'Lessons Learned' section of the response report?
0/10 answered