A city engagement yields a low-privilege Linux shell on an internal host. What should the tester do first for privilege-escalation situational awareness?
Select an answer to reveal the explanation.
Short Explanation
Before you rummage the entire toolbox, check whose boots you are wearing and what room you are in. On a fresh low-priv Linux shell, identity, host role, and obvious misconfig checks beat random exploit downloads. Skipping the whole phase or silencing audit without approval is not the move.
Full Explanation
After obtaining a low-privilege Linux shell on an internal city host, privilege-escalation situational awareness comes first: establish identity (whoami/id), host role, OS/build, sudo rights class, interesting file permissions, and scheduled tasks before shopping public exploits. Enumeration prevents noisy, irrelevant, or RoE-violating attempts.
Immediately downloading every public kernel exploit without identifying host role is reckless. Disabling auditd without approval to hide enumeration noise violates professional conduct. Assuming root is unreachable and skipping Linux priv-esc entirely abandons in-scope methodology.
Exam caveat: CPTS-style judgment favors common misconfigurations before fragile kernel races, especially on civic production hosts.
Operational check: run authorized baseline identity and host inventory commands, note sudo -l class results and obvious SUID/cron issues, then choose techniques that match evidence. Document the host's civic function so impact statements reflect resident-facing services. In municipal operations, record the rationale in the engagement notes so future assessors know which control was chosen and which failure modes the rejected options would create for city services.