SOC Lab Project Implementation with Wazuh SIEM Part 2
From Docker to Detection: Building a Red & Blue Team Lab with OWASP Juice Shop and Wazuh
1. Introduction
What you set out to build
Why Red Team + Blue Team
Objective: Exploiting a vulnerability and detecting it in Wazuh
Lab Diagram:
Kali Linux
│
│ SQL Injection
▼
Ubuntu Lab
│
├── Docker
│ └── OWASP Juice Shop :3000
│
└── Wazuh Agent
│
▼
Wazuh Manager
│
▼
Wazuh Dashboard
2. Lab Environment
Detailed component breakdown:
| Component | Role |
| MacBook Air M4 | Hypervisor / management |
| Kali Linux | Red Team / attacker |
| Ubuntu Lab | Victim / application server |
| Docker | Containerization |
| OWASP Juice Shop | Vulnerable web application |
| Wazuh Agent | Log collection |
| Wazuh Manager | SIEM / detection |
| Wazuh Dashboard | Visualization |
3. Installing Ubuntu Server
Core configuration steps:
Installing Ubuntu Server on Fujitsu
Network configuration
SSH setup
IP verification
Commands:
ip addr
hostname -I
sudo apt update && sudo apt upgrade -y
SSH installation:
sudo apt install openssh-server -y
Verification:
sudo systemctl status ssh
Accessing the server from Mac:
ssh ubuntu_lab@192.168.0.152
4. Installing Docker
Exact installation steps:
sudo apt update && sudo apt install docker.io -y
Verification:
docker --version
sudo systemctl status docker
Testing the environment:
sudo docker run hello-world
Why Docker is useful for a cyber lab:
The vulnerable application can be isolated inside a container without installing its dependencies directly on the host.
5. Deploying OWASP Juice Shop
Container deployment command:
sudo docker run -d \
--name juice-shop \
-p 3000:3000 \
bkimminich/juice-shop
Verification:
docker ps
Access URL: [http://192.168.0.152:3000](http://192.168.0.152:3000)
Real-world troubleshooting:
Conflict. The container name "/juice-shop" is already in use
Investigating existing containers:
docker ps -a
Documenting real-world troubleshooting steps adds practical value over a pristine script.
6. Reconnaissance from Kali
Target discovery:
Nmap:
nmap -sV -sC -p 3000 192.168.0.152
-sV→ Service/version detection-sC→ Default NSE scripts-p 3000→ Scan only the Juice Shop portNikto:
nikto -h http://192.168.0.152:3000
Key distinction:
Scanner finding vs. Confirmed vulnerability
Example: Nikto may report numerous "interesting" paths, but these require manual validation before being classified as confirmed vulnerabilities.
7. Installing and Configuring Wazuh Agent
Architecture flow:
Ubuntu Lab ──> Wazuh Agent ──> Wazuh Manager
Key execution steps:
Agent installation
Manager IP configuration
Agent registration/identification
Starting the agent service
Connection verification
Commands:
sudo systemctl status wazuh-agent
sudo tail -f /var/ossec/logs/ossec.log
8. Connecting Docker Logs to Wazuh
Docker utilizes the JSON logging driver, storing container logs at:
/var/lib/docker/containers/<container-id>/<container-id>-json.log
Identifying the specific log path:
docker inspect juice-shop --format '{{.LogPath}}'
Monitoring live container output:
sudo tail -f "$(docker inspect juice-shop --format '{{.LogPath}}')"
Architectural insight:
Juice Shop does not output raw HTTP request details to standard Docker logs by default—only startup/runtime messages. Merely deploying the Wazuh Agent does not automatically grant full application layer visibility without targeted log ingestion.
9. SQL Injection – Red Team Phase
Vulnerability mechanics:
User input ──> SQL query ──> Database
Exploitation occurs when untrusted user input is parsed directly as executable SQL code.
In Juice Shop, SQL Injection was used to bypass authentication before targeting the REST API.
Note: All commands and payloads are designated for Lab-only / intentionally vulnerable applications.
10. Exploiting the REST API
API Attack Path:
Kali ──> /rest/products/search ──> SQL Injection ──> SQLite ──> Database error / response
Structured attack breakdown:
Determining column count
Confirming SQL Injection entry points
UNION-based SQL Injection
Database schema enumeration
Assessing impact
11. Blue Team Investigation
After successfully exploiting the application, I switched to the defender's perspective.
Analyzing attack signatures left in telemetry:
SQL syntax errorUNIONSELECTSQLite error
Event ingestion pipeline:
Juice Shop ──> Docker JSON logs ──> Wazuh Agent ──> Wazuh Manager
12. Custom Wazuh Detection Rule
Key defensive tasks:
Identifying why default rules failed to trigger
Isolating log patterns inside
local_rules.xmlConfiguring severity Level 8
Validating rule syntax and logic
Verifying trigger alerts
13. Wazuh Dashboard Alert
Alert processing pipeline:
SQL Injection ──> SQLite / Node.js error ──> Docker log ──> Wazuh Agent ──> Wazuh Manager ──> Custom Rule ──> 🚨 Alert
Extracted telemetry fields:
Timestamp
Agent ID/Name
Source path
Rule ID
Severity Level
Raw log payload
Detection reason
14. Red Team vs Blue Team
| Red Team | Blue Team |
| Nmap scanning | Log monitoring |
| Nikto web scanning | Wazuh SIEM deployment |
| SQL Injection exploitation | Log analysis & correlation |
| REST API manipulation | Detection engineering |
| Database enumeration | Custom rule development |
| Application exploitation | Incident alerting |
15. Lessons Learned
Vulnerability ≠ Detection: An active application vulnerability does not guarantee automatic detection by a SIEM.
Logging is critical: Without granular telemetry, the Blue Team operates blindly.
Default SIEM rules aren't always enough: Custom detection logic tailored to specific application logs is necessary.
Offensive testing improves defensive detection: Understanding exact attacker interaction patterns enables precise artifact detection.
16. Final Architecture
Video - https://youtu.be/-L7ZxvekWeU
Comments
Post a Comment