A city grants VPN access for an Active Directory-focused internal assessment. How should the tester characterize the starting posture?
Select an answer to reveal the explanation.
Short Explanation
VPN keys put you in the lobby, not out on the sidewalk. Internal AD work starts from that inside seat — different first moves than poking the public edge. Do not pretend you are still outside once you dialed in with permission.
Full Explanation
When a city grants VPN access for an Active Directory-focused internal assessment, the starting posture is an internal assessment that begins from an inside vantage once that authorized VPN path is available. The tester should not insist on repeating an external edge port-scan prelude as if the VPN did not exist; external work is a different scope unless also authorized. VPN access does not imply a physical red-team or badge-cloning exercise. Active Directory assessment over VPN is squarely within common CPTS-style internal methodologies and is not out of scope merely because AD is involved. Exam caveat: VPN credentials and jump-host rules are themselves RoE controls—stay inside provided paths and do not pivot into unauthorized tenants. Operational check: confirm VPN user rights, DNS, and target OU or subnet lists in the scope document, connect through the approved concentrator, and begin enumeration from that internal vantage while logging source IPs for the city's SOC. Keep the explanation tied to authorized civic scope, documented rules of engagement, and evidence that a reviewer can reproduce without guessing. Prefer precise technical language over slogans, and separate what was observed from what was successfully exploited under permission.