🏠 Overview 🗺️ Reference Maps 🔐 Crypto Lab 🛡️ Security Device Lab
🧯 IR Playbook
🔍 Vulnerability Lab
🧬 Digital Forensics
📄 CERT Report
🔴 Red Team 📋 CMM Assessment 🏛️ CII Evaluation
Team—
Solved0 / 11
Score0 / 220
Progress0%
⏱ Elapsed00:00
📋 Problem
🔧 Fix Config
✅ Grade
🚨 Incident Report
The SOC team received a critical alert. An external IP 203.0.113.99 successfully established an SSH connection to the server (10.0.0.1) and gained root access.

Firewall logs confirm the traffic was ACCEPTed. The network admin insists "SSH was restricted to internal network only."
📌 Your Tasks
1Analyze the current firewall ruleset and identify the vulnerable rule
2Determine why external SSH access was possible
3Remove the vulnerable rule and add a default-deny rule to harden the firewall
Current Firewall Rules Loading...
Red rows = vulnerable rules (recommended to delete)
Add New Rule
📋 Clicking Grade runs 4 automated packet tests
① Block external SSH   ② Block external Telnet   ③ Allow external HTTP   ④ Allow internal SSH
Current config: loading… — review on the Fix Config tab before grading.
📋 Problem
🔧 Fix Config
✅ Grade
🚨 Incident Report
An attacker used SSH brute force to compromise the root account, then successfully uploaded a web shell (shell.php) to the web server. Neither attack triggered any IDS alert, and a subsequent reverse shell connection was also undetected.

The security team had previously disabled several signatures to "reduce false positives." Additionally, the IDS is running in detection-only mode — even when traffic is detected, it is not blocked.
📌 Your Tasks
1Find all disabled signatures and re-enable them
2Switch from IDS mode to IPS mode so detected attacks are actively blocked
IDS / IPS Mode
🔍 IDS — Detect Only
🛡️ IPS — Detect + Block
Signature Management
📋 Grading criteria
① SSH Brute Force (SID 4001), HTTP Brute Force (4002), Web Shell (5002), Reverse Shell (6002) — all enabled
② Mode set to IPS (detect + block)
Review your signature toggles and mode selector on the Fix Config tab before grading.
📋 Problem
🔧 Fix Config
✅ Grade
🚨 Incident Report
An employee's corporate communications were intercepted while using VPN over public Wi-Fi at a coffee shop. Additionally, a former employee used leaked credentials to gain unauthorized VPN access.

Investigation revealed the VPN was configured with a legacy protocol for "Windows XP compatibility," a shared pre-shared key still known to ex-employees, and internet traffic was leaking outside the VPN tunnel.
📌 Your Tasks
1Replace the weak VPN protocol and cipher with modern, secure alternatives
2Replace the shared Pre-Shared Key (PSK) with per-user Certificate (PKI) authentication
3Change tunnel mode so all traffic is routed through the VPN
VPN Configuration
Change a setting above to enable Apply
Security Assessment
Change a setting to see the security assessment.
📋 Grading criteria
① Protocol: WireGuard, OpenVPN, or IPSec/IKEv2
② Cipher: AES-256-GCM, AES-128-GCM, or ChaCha20
③ Auth: Certificate (PKI) or MFA + Certificate
④ Tunnel Mode: Full Tunnel
Review your selections on the Fix Config tab before grading.
📋 Problem
🔧 Fix Config
✅ Grade
🚨 Incident Report
The service was completely unavailable for 2 hours. The attacker simultaneously launched a SYN Flood (exhausting the TCP connection table) and an HTTP Flood (overwhelming the application layer).

The ops team had disabled SYN Cookie because "it added 5ms of latency," and turned off L7 HTTP protection and CAPTCHA to "improve mobile user experience." The configured rate-limit threshold was also far too high to be effective.
📌 Your Tasks
1Enable SYN Cookie to defend against SYN Flood attacks
2Enable HTTP Flood protection and CAPTCHA to block Layer 7 attacks
3Enable WAF as an additional layer of defense against complex attacks
Enable / Disable Defenses Red border = required
📋 Grading criteria
① SYN Cookie enabled
② HTTP Flood protection (WAF) enabled
③ CAPTCHA enabled
Review your active defenses on the Fix Config tab before grading.
📋 Problem
🔧 Fix Config
✅ Grade
🚨 Incident Report
An attacker operated undetected inside the internal network for 3 weeks. The full kill chain — reconnaissance → initial access → C2 communication → data exfiltration — generated zero SIEM alerts.

Post-incident analysis revealed the SOC team had disabled Brute Force Detection (CR-001), APT Kill Chain Detection (CR-006), and Account Takeover Detection (CR-008) due to "alert fatigue." Each stage was logged, but no correlation alert was ever raised.
📌 Your Tasks
1Find all disabled correlation rules and re-enable them
2Verify that all HIGH and CRITICAL severity rules are active
Correlation Rule Management Click a rule to toggle it
📋 Grading criteria
① CR-001 (Brute Force Attack) — enabled
② CR-006 (APT Kill Chain) — enabled
③ CR-008 (Account Takeover) — enabled
Review your correlation rule toggles on the Fix Config tab before grading.
🚨 Incident Report
💡 Toggle Hint
📋 Diagnosis Results
Submit a diagnosis to see your results here.