Scenario 1: Network Reconnaissance & Exploitation

Field	Value
Internal ID	01
Type	Offensive (attacker, from Kali)
Difficulty	Easy (level 1); lab time limit 30 minutes
Tasks	5: four auto-scored milestones and one flag task, total 275 points
Scored on	Kali container (SCENARIO_TARGETS[1] = "kali"); Task 5 by flag submission
Lab surface	terminal, Kali tab only (no meta tab, so commands cannot be run on the wrong host)
Guide	cyberrange/portal/public/scenarios/scenario_01_network_reconnaissance.md

ExplainerScenario 1: Network Reconnaissance & Exploitation1:09

Objectives

The student, acting as an attacker on Kali, works through the first phases of an engagement against the meta target: find which hosts are alive, enumerate open ports, fingerprint the services, gain a shell on the target's Tomcat Manager, which ships with a default credential, and finish by reading a personal flag file on Kali and submitting the token it holds. This scenario is the attacker's view of the same weakness that Scenario 4 later remediates.

Concepts

Host discovery, TCP port enumeration, service and version fingerprinting, choosing an exploit from version information, and why a default credential on an administrative interface leads to remote code execution. The guide explains each step before the student runs it.

Topology, roles and machines

Machine	Address	Role in this scenario	Terminal user
Kali	10.0.(50+N).10	Attacker workstation	student
meta	10.0.(50+N).20	Primary target	msfadmin
dvwa	10.0.(50+N).30	Secondary target for optional scans	student

• Network: the student's own pod-N-net, peered only to the monitoring network. Kali has $TARGET_META and $TARGET_DVWA exported in its shell.
• Target services on meta: FTP (21), SSH (22), HTTP (80) and Tomcat Manager (8180). The Tomcat Manager credential is the intended entry point.

Tools

Nmap (host discovery, port and version scanning) and Metasploit, both preinstalled in the Kali golden image. No tools are installed at runtime.

Vulnerability

A default administrative credential on the Tomcat Manager interface. This is a configuration weakness, not a software flaw. It is present only inside the disposable lab target, baked into the meta-base golden image, and destroyed with the lab.

Milestones, checks and evidence

The first four checks read evidence inside the Kali container. Milestones 1 to 3 read the student's shell history (flushed after every command by enable_history_flush.sh) and confirm the command actually targeted this lab; Milestone 4 inspects live process and socket state. Task 5 is a flag the student submits.

#	Milestone	Points	What the check verifies	Source
1	Host Discovery	50	A host-discovery scan of this lab's own /24 appears in history, and the container currently has a route to that subnet (guards against a command that never worked because the interface was down)	check_scenario_1 case 1
2	Port Enumeration	50	A port scan (-p or -F) in history is aimed at this lab's .20 or .30, in either argument order	check_scenario_1 case 2
3	Service Version Detection	50	A version scan (-sV) in history is aimed at this lab's .20 or .30	check_scenario_1 case 3
4	Tomcat Manager Exploitation	75	A live Metasploit session in the tmux lab pane: the pane runs Metasploit, its output shows a Tomcat Manager session opened after run or exploit was entered at the tomcat_mgr_deploy module prompt, to this lab's .20, and the Metasploit process still owns an established socket to that address (check_live_tomcat_msf_session). The pane must be the only one in the lab session, so a session from a msfconsole -x one-liner, a resource script or another pane is not credited (the guide says so since pull request 278)	check_scenario_1 case 4
5	Capture the Flag	50	Back in the normal Kali shell, the student reads the flag file planted on Kali (/opt/cyberrange/flags/scenario1.txt, root-owned, world-readable) and submits the FLAG{S01_M5_…} token it prints. The token is a per-student HMAC (COHORT_FLAG_SECRET); usernames such as student or tomcat are rejected. Validation requires the stored flag to have that exact shape and compares in constant time, case-insensitively. Flag-only: a correct value alone scores; a wrong one scores nothing. Pull request 181 replaced the earlier "submit your Kali username" answer.	PURE_FLAG_MILESTONES, validate_flag() in rubrics.py, plant_scenario1_kali_m5() in flag_planting.py, schema/v12.sql

The subnet for Milestones 1 to 3 is derived from the container's own eth0, so a scan aimed at a different lab's subnet does not count.

Completion detection

The milestone poller runs every 3 seconds against Milestones 1 to 4 while the lab is ACTIVE (it never polls the flag task). If auto-detect misses a task, the student has one Manual Check for it; a failed check locks the task to instructor review. Task 5 scores when the flag is submitted from the exercise panel's Status area. A PASS is written once. The scenario is complete when all five tasks have a PASS; the score is 275.

In the lab page the tasks unlock in order (Task 2 opens when Task 1 is done, and so on); completed tasks stay open for review. The Kali pane is labelled Host: because Kali is the student's own machine.

Logs and evidence

• milestone_verification rows (one per check, PASS or FAIL) and audit_log MILESTONE_VERIFIED events.
• Per-student flags are planted on meta at provisioning as supplementary artifacts for Milestones 1 to 3 (a robots.txt comment, an FTP banner and a Tomcat page comment). Milestone 4 is behavioral; stray flag files from earlier designs are removed from meta so students do not submit the wrong value.
• The Task 5 flag is planted on Kali and saved for the lab. For Scenario 1 this step is fail-closed: if the Kali write or the save fails, provisioning raises a generic "Scenario 1 flag planting failed" error and the lab never becomes ACTIVE; the audit row (FLAGS_PLANTED_FAIL) records only an allowlisted reason, never the flag (plant_flags_during_provision() in provision.py, Scenario1FlagPlantingError). Other scenarios keep flag planting non-fatal. The guide tells a student whose flag file is missing to ask for the lab to be restarted.
• A Task 5 PASS row has detection_data = 'pure_flag_capture'.
• Instructor diagnostics (pull request 261, off unless SCORING_DIAGNOSTICS_SCENARIOS includes 1): a failed check records a reason code such as NO_SUBNET_ROUTE, COMMAND_NOT_FOUND (no real nmap run), COMMAND_NOT_MATCHED (an nmap run aimed elsewhere), MSF_NOT_RUNNING, SESSION_NOT_OPENED or SESSION_NOT_LIVE. See Lifecycle & Scoring.
• The scoring script logs to /var/log/cyberrange-scoring.log inside the container.

Standards mapping

Framework	Mapping	Note
MITRE ATT&CK (portal)	T1046 Network Service Discovery	Applied to the whole scenario
MITRE ATT&CK (M4, rubric seed)	T1190 Exploit Public-Facing Application	The default-credential entry is also close to T1078.001 (Default Accounts); see Open Questions D10
MITRE ATT&CK (M5, rubric seed)	T1083 File and Directory Discovery	Seeded in schema/v10.sql
OWASP	Not tagged in code	Closest: A07:2021 Identification and Authentication Failures (default credential)

OWASP mappings are not present in the repository and are offered here only as the closest fit.

Documentation vs implementation

• D1 (resolved): the rewritten guide now tells the student to keep the remote session open until Task 4 is credited, matching the live-session check.
• D16 (superseded): pull request 181 replaced the Kali-username answer with a planted per-student flag file; the catalog, guide, rubric (schema/v12.sql) and code comments now agree, and read_kali_whoami() is gone. One stale comment remains in flag_planting.py ("M4 is scored from Metasploit history"), although M4 is the live-session check. See Open Questions.

Safety

Offensive tools run only inside the student's own lab network, which is not peered to any other lab. The vulnerable target exists only in the lab and is destroyed at teardown. The student has sudo only inside their own unprivileged containers.