A city after-action review finds command injection through an intranet admin page that exposed unsanitized traceroute-style tools. Which recognition best captures the pattern?
Select an answer to reveal the explanation.
Short Explanation
That friendly intranet 'traceroute' box is often just a shell microphone. Internal-only and pretty themes do not sanitize OS calls. Call the pattern by its name in the after-action.
Full Explanation
Unsanitized intranet admin network-diagnostic tools—traceroute, ping, dig wrappers—that pass user input into OS commands are a classic command-injection pattern. After-action recognition should name that pattern clearly: internal-only deployment and municipal theming do not sanitize shell execution. City intranet admin pages have repeatedly been real-world CMDi sources because convenience diagnostics are wired straight to the OS.
Claiming intranet admin diagnostic tools can never be abused because they are internal-only ignores insider, phishing-session, and pivot realities. Treating traceroute-style helpers as risk-free if the page uses a municipal theme confuses branding with input safety. Saying command injection on admin tools only matters for internet-facing marketing sites arbitrarily narrows impact; internal admin compromise often has higher operational consequence.
Exam caveat: pattern-recognition stems about unsanitized traceroute-style admin tools map to classic command injection, not 'internal = safe.' Operational check: find admin diagnostics that shell out, test only under ROE with safe detection, fix via allowlists/avoid shell, and record the pattern name in the AAR.