Municipal IT asks for a map of guest-Wi-Fi SSIDs around City Hall. Which PORP-appropriate method should the analyst use?
Select an answer to reveal the explanation.
Short Explanation
Wireless OSINT here is looking at the public map, not picking the lock. Pull the observed SSIDs and pins from a wardriving-class dataset and date the pull. Handshake hunts, deauths, and fake APs belong to a different cert.
Full Explanation
PORP wireless work for mapping guest Wi-Fi around City Hall is observational. The appropriate method is to query a public wardriving-class dataset for observed SSIDs, BSSIDs, and approximate locations near the civic building, then cite the dataset, query area, and observation dates. That gives municipal IT a public-source map product without recovering keys or transmitting on the plaza.
Capturing WPA handshakes and recovering keys to confirm ownership is offensive wireless key attack, outside PORP even when the target is a city plaza. Deauthenticating visitors so devices reveal hidden SSIDs is an active RF attack against patrons. Standing up a rogue City Hall access point to harvest associations is a honeypot-style attack, not open-source mapping.
Exam caveat: map pins do not by themselves prove municipal ownership of an SSID; names collide, visitor hotspots appear, and corpora age. Report observed names and locations with vintage, and leave ownership confirmation to IT inventory where needed.
Operational check: pull the wardriving-class query for the City Hall vicinity, export SSIDs/BSSIDs with timestamps, compare lightly to any published guest list, and deliver the dated map notes to IT—without handshake capture, deauth, or rogue APs.