River Station 14
You are part of the incident-response team for a river monitoring station. A severe storm, conflicting telemetry, and gaps in the station's chain of trust have made its records difficult to rely on. Investigate six evidence stations, decide which claims the records support, and recommend a response that protects the investigation without claiming that device data alone proves whether the river is safe or contaminated.
Learning goals
By the end of this track, you will be able to:
- correlate access logs, commissioning records, configurations, firmware strings, telemetry, and event records;
- distinguish matching bytes from authenticated software provenance;
- explain how exposed or reused credentials weaken a system's chain of trust;
- identify replay evidence by comparing message identity, sequence, payload, sensor time, and receipt time;
- test whether a server trusts client-controlled information across a proxy boundary; and
- evaluate claims against specific evidence, respect the limits of each finding, and connect a corrective control to its demonstrated failure.
Before you begin
Connect to the assigned Pocket CTF network and open the game as described in the connection guide. Read the scenario-track workflow and keep an evidence log with the artifact, observation, tool or action, and interpretation for each finding. The glossary defines shared web, evidence, and cryptography terms.
Work only with the provided station and evidence routes. The board is a small, single-threaded device: send one request at a time and do not scan, flood, or brute-force it. The evidence is synthetic, but the distinction between a cybersecurity conclusion and a public-safety conclusion is part of the exercise. Record uncertainty instead of filling a gap with an assumption.
Recommended tools
- Browser and text editor: Open station pages, download evidence, search text, and compare small records side by side.
- JSON or JSON Lines viewer: Use a text editor,
jq, or a short local script to format records without changing their field names or order. - HTTP client: Browser developer tools or
curlcan inspect requests and send an instructor-approved custom header. Preserve the current session and make one controlled change per request. - Timeline workspace: Paper, a text table, or a spreadsheet can separate event time, receipt time, source, observation, and interpretation.
The student guide provides safe HTTP recipes, and its data and file recipes cover structured records, hashes, readable strings, and time normalization.
Modules
| Module | Focus | Estimated time |
|---|---|---|
| Maintenance Window | Access logs and unfinished commissioning controls | 30 min |
| Calibration Package | File integrity and publisher authentication | 30 min |
| Service Credential | Secrets exposed across firmware and configuration | 30 min |
| Echo in the Rain | Replay evidence across sensor and receipt records | 35 min |
| Trusted Gateway | Client-controlled headers and proxy trust | 35 min |
| Safety Decision | Evidence-backed verdicts and replay-control reasoning | 30 min |
Suggested pacing
Complete the modules in order. The first five examine separate weaknesses and evidence types used in the final incident-response decisions. Partners may divide tool operation and note-taking, but each learner should be able to connect an observation to the conclusion it supports.
After establishing a finding, copy its seal and file it on the incident board. Do not treat a seal as a substitute for an evidence note. Before starting Safety Decision, read the operations note and compare the earlier findings. The final form requires three verdict/evidence pairs and one replay-control choice. The event index remains a reference; there is no sequence to submit. The revised 30-minute estimate requires classroom validation, and earlier board verification does not cover this new form.
Completion and reflection
The track is complete when all six finding seals have been filed and the incident report is available. A strong investigation also explains which records remain useful, which conclusions require independent confirmation, and why the recommended response fits the uncertainty in the evidence.
After reviewing the incident report, ask:
- Which conclusion required two or more artifacts rather than one record?
- Where did a technical control establish integrity without establishing authorization or origin?
- Which observation weakened trust in later station data?
- What can the digital evidence establish about the station, and what can it not establish about the river?
- How does the recommended response preserve evidence while reducing risk?