Final Project: Red/Blue Capstone Exercise
Due: 14 August 2026
Submission: GitLab repo secdevops-s26-<CECS>

• Overview
• Prerequisites
• Setup (15 minutes)
  • Take pre-capstone snapshots
  • Verify the monitoring stack
  • Confirm DVWA is running
• Rules of Engagement
• Red Phase — Attacks
  • Required minimum: choose at least three
  • Attack log format
• Transition
• Blue Phase — Analysis
  • For each attack you conducted
  • Correlation exercise
  • Active response verification
• Post-Mortem Report
  • Required sections
• Grading Criteria
• Submission

Overview

The capstone is a structured red/blue exercise against the system you have spent seven weeks building. You will attack your own DVWA instance using techniques covered in the course, then pivot to the blue team role and analyze what your monitoring stack detected. The final deliverable is a post-mortem report that honestly documents what worked, what failed, and what you would improve.

This exercise is not a test of whether you can break DVWA — DVWA is designed to be broken. It is a test of whether your detection stack works, whether you can interpret what it shows you, and whether you can articulate the gaps honestly. A student who finds two attacks and explains every alert in detail demonstrates more mastery than one who runs ten attacks and cannot explain a single one.

Prerequisites

All of the following must be complete and functional before beginning the capstone:

• Week 1 Part 1: All three VMs running (Kali, ubuntu-server, wazuh)
• Week 2 Part 1: SSH hardened, fail2ban configured
• Week 2 Part 2: OpenBao running, no plaintext credentials
• Week 3 Part 2: Hardened docker-compose.yml stack running (nginx → DVWA → MariaDB)
• Week 4 Part 2: Wazuh agent active on ubuntu-server
• Week 6 Part 2: nftables rules applied, fail2ban active
• Week 7 Part 1: Custom Wazuh brute-force and container spawn rules active
• Week 7 Part 2: Suricata running with EVE→Wazuh integration, FIM configured

Setup (15 minutes)

Take pre-capstone snapshots

Before any attack activity, take a snapshot of all three VMs. This is your forensic baseline and your recovery point:

for vmid in 200 201 202; do
  qm snapshot $vmid pre-capstone \
    --description "Pre-capstone snapshot $(date +%Y-%m-%dT%H:%M:%S)"
done

Verify the monitoring stack

Confirm that all detection layers are active before beginning:

# On ubuntu-server
sudo systemctl is-active wazuh-agent suricata fail2ban nftables
# All four must show: active

# On wazuh (10.10.10.30)
sudo /var/ossec/bin/agent_control -l
# ubuntu-server must show: Active

Open the Wazuh dashboard (https://10.10.10.30) and confirm it is reachable and showing recent events from ubuntu-server.

Confirm DVWA is running

curl -s -o /dev/null -w "%{http_code}" http://10.10.10.20/
# Must return 200 or 302

Rules of Engagement

Read these before beginning the red phase.

1. Scope: Attacks are limited to your own lab environment. You may only target the IPs assigned to your VMs (10.10.10.10, 10.10.10.20, 10.10.10.30).

2. Proxmox host boundary: The Proxmox host itself (172.19.100.x) is out of scope. Do not attempt to escape to the hypervisor.

3. Tools: Use only tools installed on Kali. Do not download additional tools during the exercise.

4. Documentation requirement: Every action taken during the red phase must be logged with a timestamp and the exact command used. Undocumented attacks cannot be analyzed in the blue phase.

5. Duration: The red phase is 60 minutes. When time is called, stop all attack activity immediately and switch to the Wazuh dashboard.

Red Phase — Attacks

Conduct at least three of the following attacks. For each attack, document the timestamp, the tool and flags used, and what you observed. You are free to conduct additional attacks from the list.

Required minimum: choose at least three

Reconnaissance

# Network scan — identify open ports and services
nmap -sV -p- 10.10.10.20

Web application brute force

# Brute force DVWA login with a small wordlist
hydra -l admin -P /usr/share/wordlists/fasttrack.txt \
  10.10.10.20 http-post-form \
  "/dvwa/login.php:username=^USER^&password=^PASS^&Login=Login:Login failed"

SQL injection Navigate to http://10.10.10.20/dvwa/vulnerabilities/sqli/ in a browser (set DVWA security to Low). Manually extract the database version and user table using SQL injection. Document the payload that worked.

Alternatively, use sqlmap:

# Set a session cookie first (log in via browser and copy the PHPSESSID)
sqlmap -u "http://10.10.10.20/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit" \
  --cookie="PHPSESSID=<cookie>; security=low" \
  --dbs --batch

Command injection Navigate to http://10.10.10.20/dvwa/vulnerabilities/exec/. Inject a command alongside a valid IP: 127.0.0.1; id. Document the output.

File inclusion Navigate to http://10.10.10.20/dvwa/vulnerabilities/fi/?page=../../../../etc/passwd. Document what you can read.

Privilege escalation (if initial access is gained)

If you achieve RCE inside the DVWA container via command injection, attempt to enumerate SUID binaries:

find / -perm -4000 -type f 2>/dev/null

Document your findings. Attempt privilege escalation only if a viable path exists.

Persistence attempt (if shell access is gained)

If you obtain a shell inside the DVWA container, attempt to write a file that would persist across container restarts. Document whether the read-only filesystem from Week 3 Part 2 prevents it.

Attack log format

Record every action in capstone/attack-log.md as you go. Use this format:

| Time | From | Target | Tool / Command | Outcome |
|------|------|--------|----------------|---------|
| 14:23:01 | Kali | ubuntu-server:80 | nmap -sV -p- 10.10.10.20 | 3 ports open: 22, 80, 3306 |

Transition

When the red phase ends:

1. Stop all attack tools on Kali.
2. Do not SSH into ubuntu-server or touch the Wazuh manager. From this point, treat the Wazuh dashboard as your sole source of truth.
3. Note the exact time the red phase ended.

Blue Phase — Analysis

Work entirely from the Wazuh dashboard (https://10.10.10.30). Do not touch ubuntu-server directly during this phase.

For each attack you conducted

1. Find the corresponding Wazuh alert (or confirm it is absent).
2. Record: rule ID, rule description, alert level, timestamp.
3. Calculate detection latency: time between your attack command and the Wazuh alert timestamp.
4. If no alert fired: identify which detection layer should have caught it and why it did not.

Correlation exercise

Construct a timeline of events from the Wazuh dashboard covering the entire red phase. The timeline must be grounded in actual alert timestamps — do not use your attack log. Compare the dashboard timeline to your attack log. Where do they agree? Where are there gaps?

Active response verification

For each active response that fired (fail2ban ban, firewall-drop), confirm:

• The alert that triggered it
• The action taken
• Whether the active response correctly contained the attack or just slowed it down

Post-Mortem Report

The post-mortem is the primary deliverable. It must be honest. A gap that is identified and explained is more valuable than a gap that is hidden.

Required sections

1. Attack log (capstone/attack-log.md)

The complete timestamped table of every action taken during the red phase. Must be filled in during the red phase, not reconstructed afterward.

2. Detection log (capstone/detection-log.md)

For every attack in the attack log, a corresponding entry:

3. Gap analysis (capstone/gap-analysis.md)

For every attack that was not detected, write a structured entry:

### Gap: [Attack name]

**What happened**: [describe the attack]
**Detection layer that should have caught it**: [network / host / application]
**Root cause of miss**: [no rule, wrong log source, threshold too high, etc.]
**Proposed improvement**: [specific rule, configuration change, or new tool]
**Estimated implementation effort**: [Low / Medium / High]

4. Reflection (capstone/reflection.md)

Write 400–600 words covering:

• Which aspect of the system’s security surprised you most, in either direction (stronger or weaker than expected)?
• What is the most important thing you learned about the relationship between preventive controls and detection?
• If you were deploying this system in a real production environment, what would you change first?

Grading Criteria

Submission

Create capstone/ in your GitLab repo containing all five components listed above. Commit and push before the deadline.

The capstone cannot be submitted late without prior arrangements.