The MesaNet Portal hosts a "Rail Broadcasts" application accessible through a JSON gateway API. A low-privilege operator account can interact with several broadcast endpoints, but a confidential note owned by a privileged automated user sits just out of reach. The challenge requires chaining the broadcast creation pipeline with the automated oversight system to escalate access without ever touching the privileged session directly.
Objective: Plant the XSS payload in broadcasts covering every 5-minute slot of the simulated facility clock (288 broadcasts total) so that whichever instant the bot fires, a malicious broadcast is guaranteed to be selected.
Context: The broadcast selection algorithm picks a single broadcast based on the simulated facility clock, `priority`, and `timestamp`. You don't know the exact clock value the bot will see. A single broadcast with one timestamp may not match. Automating 288 sequential `POST /gateway → /api/rail/create` calls, one per 5-minute increment (00:00:00, 00:05:00, … 23:55:00), all with `priority: "high"`, eliminates the timing dependency entirely.
Only reveal the ones you need. Claude tracks how many you used to calibrate the feedback.
You need the same payload stored at every possible 5-minute timestamp. Think about Burp Intruder — what payload type can generate all `HH:MM:00` combinations from `00:00:00` to `23:55:00` automatically?
In Burp Intruder, mark only the `timestamp` value as the injection position. Use a **Custom iterator** payload type: Position 1 = hours 00–23, Position 2 = literal `:`, Position 3 = minutes `00,05,10,15,20,25,30,35,40,45,50,55`, Position 4 = literal `:00`. This generates exactly 288 combinations.
Send the Repeater request for one working high-priority broadcast to Intruder (right-click → Send to Intruder). In Positions, clear auto-marks and mark only the timestamp string. Set up the Custom iterator as described. Set the resource pool to 1 concurrent request. Start the attack and wait for all 288 rows to return HTTP 200.