A municipal RoE bans reverse shells but allows SSH-based forwards when valid credentials exist. How should the tester choose a pivot channel?
Select an answer to reveal the explanation.
Short Explanation
If the client says reverse shells are off-limits but SSH forwards with real creds are fine, that is the menu—not a suggestion box. Approved channels beat clever banned ones. You adapt to the RoE and the auth you actually have.
Full Explanation
When municipal RoE bans reverse shells but allows SSH-based forwards given valid credentials, the tester should use RoE-approved SSH forwards with available authentication instead of banned reverse shells. Using reverse shells anyway because they are faster violates explicit policy. Ignoring credentials to force a banned channel for completeness is unjustifiable. Picking whichever covert channel is trendiest on social media is not a professional selection method for city work. Exam caveat: channel choice is an authorization decision first, a convenience decision second. Operational check: confirm SSH credential legitimacy under scope, establish the approved forward, document the channel for SOC visibility, and never “prove” a banned reverse shell on municipal hosts. In municipal operations, record the rationale in the engagement notes so future testers and city defenders understand which approach was chosen and which failure modes the rejected options would create for civic services. Re-validate the same judgment after the next change window so the control still holds under the city’s current tooling, identity posture, and RoE amendments. Keep secret material and session artifacts in the approved vaulted workflow rather than chat paste or unprotected tickets used by mixed municipal teams.