Scenario 4: Vulnerability Hardening

Field	Value
Internal ID	11
Type	Defensive (remediation, on meta)
Difficulty	Hard (level 3); lab time limit 60 minutes
Lab surface	terminal, with the meta tab open by default and marked Scored
Milestones	3, total 200 points
Scored on	meta container (SCENARIO_TARGETS[11] = "meta"), 30-second check timeout
Guide	cyberrange/portal/public/scenarios/scenario_04_vulnerability_hardening.md

ExplainerScenario 4: Vulnerability Hardening1:01

Objectives

The student remediates the exact weakness Scenario 1 exploits: the default Tomcat Manager credential on meta. They confirm the weakness, rotate or remove the credential and restart Tomcat, then prove the old credential is now rejected. This is the defender's closing of the loop.

Concepts

Why default credentials are a systemic risk, how to remediate a configuration weakness safely (change, restart, verify), and closed-loop verification: proving a fix works by re-testing the attack, not just assuming it. The guide frames each task as before-evidence, fix and after-evidence.

Topology, roles and machines

Machine	Address	Role	Terminal user
meta	10.0.(50+N).20	The host being hardened; all work happens here	msfadmin (granted passwordless sudo per lab)

Kali is not required for scoring. msfadmin is granted sudo on meta during provisioning specifically so the student can edit the root-owned config file and restart the service.

The lab page reinforces this: under the tabs, meta shows "all scored work happens here (msfadmin, sudo)", and switching to Kali shows an amber "optional playground, not scored" line. The first-visit Kali/meta explainer modals are skipped in this lab because they frame Kali as the attack box. A warning cue on Task 2 says no output from the grep check means the default password is gone. Since pull request 203 the guide opens with a six-step Fast path and a plain "How scoring works" list that matches the checks below.

Tools

A shell on meta: sudo to read and edit /etc/tomcat9/tomcat-users.xml, systemctl to restart Tomcat, and curl to test the Manager endpoint. All are present in the meta-base golden image.

Vulnerability

The default Tomcat Manager credential in /etc/tomcat9/tomcat-users.xml, baked into the golden image. The file is root-owned, so inspecting it requires sudo (a plain read is denied).

Milestones, checks and evidence

The checks read the student's history, the state of the config file and a live HTTP response on meta.

#	Milestone	Points	What the check verifies	Source
1	Identify the Weakness	50	A privileged inspection of tomcat-users.xml appears in history (must use sudo; a plain read is denied and would not reveal the credential)	check_scenario_11 case 1
2	Apply the Remediation	75	The config file no longer contains the default password in either quote style; if the file was moved, falls back to a remediation command in history	check_scenario_11 case 2
3	Confirm the Exploit Path Is Closed	75	A request to the Manager endpoint with the old credential returns HTTP 401 or 403 (before remediation it returns 200), and the student's history shows a curl to the Manager with the old credential	check_scenario_11 case 3

Milestone 2 is decided by the state of the file, not merely a command in history: an edit that left the default password in place fails. Milestone 3 needs both the live HTTP response code, so it reflects reality at check time, and the student's own verification curl, so it does not pass by itself the moment Milestone 2 is fixed.

Completion detection

Same poller and one-shot Manual Check flow, 30-second per-check timeout. Complete when all three milestones have a PASS; score 200. There is no flag task and no preparation task.

Logs and evidence

• The changed config file and the Manager's HTTP response are the ground truth.
• milestone_verification rows for each check.
• Per-student flags are planted on meta at provisioning (an audit comment in the config, a catalina.out line and a closed-path flag file) as supplementary artifacts.
• Instructor diagnostics (pull request 262, off unless SCORING_DIAGNOSTICS_SCENARIOS includes 11): a failed check records COMMAND_NOT_FOUND, COMMAND_NOT_MATCHED (for example tomcat-users.xml read without sudo), DEFAULT_PASSWORD_PRESENT, CONFIG_MISSING, OLD_CREDS_ACCEPTED, MANAGER_UNREACHABLE or MANAGER_UNEXPECTED_STATUS. No password or file contents are recorded. See Lifecycle & Scoring.

Standards mapping

Framework	Mapping	Note
MITRE ATT&CK (portal)	T1548 Abuse Elevation Control Mechanism	See D10: the lab is really about removing a default account, so T1078.001 (Valid Accounts: Default Accounts) is a closer fit
NIST (rubric seed)	Vulnerability Assessment, Remediation, Verification	The nist_phase column per milestone
OWASP	Not tagged in code	Closest: A05:2021 Security Misconfiguration

Documentation vs implementation

• D10: the MITRE tag T1548 is a loose fit for a default-credential remediation; T1078.001 is closer. See Open Questions.
• D15 (resolved): the 60-minute badge is now the real lab limit, and the guide no longer gives a different estimate.

Safety

All work is inside the student's own lab on an unprivileged container; sudo is scoped to that container. The hardened service and its default credential exist only in the disposable lab and are destroyed at teardown.