A county asks what Metasploit auxiliary, exploit, and post modules are each for. Which mapping is correct?
Select an answer to reveal the explanation.
Short Explanation
Picture a job site: auxiliary is the measuring tape and flashlight, exploit is the tool that gets you in, and post is what you do once you’re already inside. Mixing those roles up wastes time and muddies your notes. Keep the purpose of each class straight and the workflow stays clean.
Full Explanation
County sponsors often blur Metasploit module classes. Correct mapping: auxiliary modules support recon and other non-session helpers; exploit modules pursue a delivery path that can yield a session when successful; post modules run after a session already exists to gather or act on that access. Claiming auxiliary always opens shells misstates its role and will send testers looking for interactive access where none was designed. Treating all three classes as shell openers by design collapses distinct lifecycle stages into one incorrect mental model. Running post modules before any exploit—and treating them as recon replacements—inverts the dependency: post assumes a live session. Exam caveat: naming alone does not prove impact; module class tells you when and how the tool is meant to be used, not how severe a municipal finding is. Operational check: before launching work against library or transit hosts, label the intended class in notes (auxiliary vs exploit vs post), confirm a session exists before post, and keep out-of-scope hosts out of any session-driven follow-on. 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.