Security Testing Tools and Evidence

The bench

Somewhere in every serious security program there is a bench. It can be a room with racks, a set of cloud instances that are deliberately disposable, or a locked laptop that only the assessment team touches. What makes it a bench is that nothing on it is in production. Every tool on it exists to take something apart, learn from the pieces, and put back only a written account of what was learned. The scanner that maps the network here, the packet capture that records a conversation there, the fuzzer that spends a week throwing malformed input at a parser, they all have one job: to produce evidence that somebody can act on.

This chapter is about that bench. The previous one made the strategy decisions: what question to ask, which test type answers it, who runs it, and what the rules of engagement say. This one goes into the instruments and the paperwork. The exam, for its part, treats the tools at two altitudes. At one altitude you need to know what an instrument does well enough to match it to a scenario: which tool proves this, which class of scanner answers that, what a given technique can and cannot establish. At the other altitude you need to know what a tool’s output is worth, which is a much better question and the one the exam rewards. A scan result is a claim. A packet capture is a claim. A fuzzer crash is a claim. The discipline of this domain, and of this chapter, is reading instruments the way an engineer reads gauges: understand what the needle measures, know how the gauge could lie, and never mistake the reading for the state of the machine.

The chapter moves down the bench in the order an assessment actually uses it. First the map: network discovery and packet capture, the instruments that say what exists and what crossed the wire. Then the match: vulnerability scanners and the standardized checks that turn fingerprints into findings. Then the applications: static and dynamic analyzers, and the fuzzers that attack parsers and state machines. Then the harder instruments: exploitation frameworks and credential testing, where the tool starts to behave like the adversary. Then the specialized benches: wireless and mobile. And finally the part that outlives every tool, the evidence habits and the report, because the whole bench exists to produce documents that decision-makers can trust.

What an instrument actually produces

Every security instrument produces evidence, and evidence has properties. Four of them are worth naming, because a finding that lacks any one of them is a finding the organization cannot defend when it matters.

The first property is reproducibility. Evidence must come with enough context that someone else could produce the same output again: the tool name and version, the exact command or configuration, the target, the time. A screenshot of a screen is weaker evidence than a command log that shows the scan, the result, and the timestamp, because the log can be replayed. Reproducibility is what separates a claim from a demonstrated claim, and NIST Special Publication 800-115, the “Technical Guide to Information Security Testing and Assessment,” builds its whole methodology, planning, discovery, attack, reporting, around the idea that a finding you cannot reproduce is not a finding yet.

The second property is provenance. Where did this evidence come from, and who handled it? For a routine assessment, provenance is mostly a matter of labeling: which tool, which version of its signature database, which scanner account, which network vantage point. For evidence that might cross into a legal proceeding, provenance escalates into chain of custody, the documented record of who possessed the evidence and when, because a court will not accept evidence whose handling cannot be traced. NIST Special Publication 800-86, the “Guide to Integrating Forensic Techniques into Incident Response,” describes acquisition, preservation, and analysis as stages with exactly that discipline behind them. The assessment world borrows the habit and rarely needs the full ceremony, but a manager should know which findings might need it: anything that will be used in a termination, a lawsuit, a regulator response, or a criminal referral.

The third property is integrity. The evidence must be shown not to have changed since it was collected. The cheap and standard mechanism is hashing: compute a cryptographic hash of the capture or image at collection time, record it, and recompute it when the evidence is later examined. If the values match, nothing was altered. Timestamps serve a related purpose, fixing evidence in time, and a capture that carries accurate time synchronization from a known source is far stronger than one that trusts a laptop clock. NIST SP 800-86 is again the reference for the forensic version of the practice, but the habit belongs on the bench: hash what you collect, record when you collected it, and keep the original untouched while working on copies.

The fourth property is completeness, which is the least mechanical and the most frequently failed. Evidence must cover the claim it supports. A packet capture that started after the incident, a scan that excluded the DMZ, a fuzzing campaign that never exercised the authenticated parser paths, each of these produces evidence that is technically real and logically hollow, because it cannot support the conclusion it is offered to support. The exam loves this failure mode: a scenario describes evidence that looks solid and is in fact too narrow, and the right answer is the one that notices what was not measured.

There is a fifth property that is not about the evidence itself but about its audience. Evidence exists to change decisions, which means it has to be legible. A raw scan export is legible to a vulnerability analyst and meaningless to a director; the same finding in business terms, this weakness sits in the path to the payment data and the demonstrated exploit took an hour, is meaningful to both. The reporting section at the end of this chapter takes up the translation. For now, hold the four properties of the evidence itself: reproducible, provable provenance, verified integrity, complete coverage.

The instrument family, mapped to the question

The strategy chapter established the rule that the question picks the test type. The same rule picks the instrument, because each instrument class answers one question and is silent on the others. Here is the map, and the exam expects you to walk it in both directions, from instrument to question and from question to instrument.

Two readings of the table matter for the exam. First, the classes are not interchangeable: when a scenario describes a need to know whether a running web application can be broken by an outside caller, the DAST answer is right and the SAST answer is a trap, because SAST never runs the code. Second, the classes compose: the same assessment typically uses discovery to find targets, scanning to name weaknesses, exploitation to prove the worst one, and packet capture to document the proof. The bench is not a menu of alternatives. It is a pipeline.

Network discovery: the map before the probe

The first instrument on the bench is the network mapper, and the one the exam is most likely to name is Nmap, the open-source network scanner. Nmap does three jobs that map directly to the discovery phase of NIST SP 800-115’s methodology. Host discovery finds which addresses are alive. Port scanning finds which services are listening. Service and OS detection finds which software is behind the port, by reading banners and probing protocol responses and comparing the results to fingerprints. Nmap’s scripting engine, the NSE, extends the scanner with hundreds of small checks that test everything from version-specific weaknesses to protocol behavior.

The mechanics matter for one exam reason: scan type changes both the evidence and the risk. A TCP connect scan completes the full three-way handshake, which is easy to detect and easy to log. A SYN scan sends only the SYN packet and treats a SYN-ACK as proof the port is open, which is faster and stealthier but still visible to a network sensor that watches for exactly that pattern. The deeper point is that the scanner’s output is an inference, not a photograph. A port that shows closed from one vantage point may be open from another, firewalls filter what the scanner sees, and a service that answers a probe may be a honeypot or a load balancer pretending. NIST SP 800-115 makes the same caution about the whole discovery phase: the map is only as good as the vantage points it was drawn from, and a map drawn from outside the perimeter is a different document from one drawn from inside.

The exam question about network discovery almost always turns on one of three discriminators. The first is active versus passive: active probing sends traffic the target can see, passive observation collects what is already on the wire and leaves no trace, and the choice depends on whether the target knows it is being assessed. The second is vantage point: internal scans see internal truth, external scans see the perimeter as an outsider does, and an assessment that claims to model an external attacker must scan from outside. The third is authorization: none of it happens without the scope and approval documents from the strategy chapter, because a network map is precisely the kind of reconnaissance that an unapproved scan makes criminal.

Packet capture: reading what crossed the wire

The second instrument is the packet capture, and the names the exam uses are tcpdump, the command-line capture tool, and Wireshark, the graphical analyzer that opens captures and reconstructs conversations. A capture is a record of frames that crossed an interface, and analysis turns those frames into a narrative: this client connected to this server, negotiated TLS 1.3, transferred this many bytes, and closed the connection.

What a capture can prove is limited in one very exam-relevant way: it sees the wire, not the content. Encrypted payloads are opaque, and the analyst sees metadata, addresses, ports, packet sizes, timing, and protocol negotiation, not the application data. That limitation is not a defect. It is the definition of what traffic analysis means, and it is why the exam pairs encrypted-channel scenarios with metadata reasoning: a capture cannot tell you what was in the HTTPS request, but it can tell you that a workstation began beaconing to a foreign address every sixty seconds at 3 a.m., which is its own finding. NIST SP 800-92, the “Guide to Computer Security Log Management,” makes the companion point about logs: captures and logs are both records of events, and an investigation is strongest when they are correlated, because the log says what the application believed and the capture says what the wire carried.

The capture also has an acquisition side that the exam occasionally tests. A capture that begins after the suspicious activity is evidence of nothing except what followed. A capture on the wrong interface, a mirror port that was never configured, a span port that dropped half the traffic, all of these produce files that look authoritative and prove little. And in enterprise environments, the “decode the encrypted traffic” capability, when it exists, comes from a deliberate design decision, an interception proxy that terminates TLS at a trusted appliance and re-encrypts to the destination, with all the trust and key-management consequences such a device carries. The default condition is that the payload is unreadable, and the exam wants you to know the difference between seeing the handshake and seeing the payload. The exam wants you to know the difference between seeing the handshake and seeing the payload, and to treat any claim of “seeing the payload” as requiring an explanation of how, because the default answer is that nobody can.

Vulnerability scanners: the match, the claim, the verification

The vulnerability scanner is the workhorse of the domain, and it is worth understanding as a machine rather than as a magic box. A scanner does three things. It fingerprints the target, using the same banner reading and version probing the discovery tools do. It matches what it found against a database of known weaknesses, the plugins and checks that encode the public knowledge in CVE, the catalog of publicly known vulnerabilities that MITRE manages under the sponsorship of CISA, with each finding identified by a CVE number issued through the CVE Numbering Authorities. And it scores what it matched, using the Common Vulnerability Scoring System, CVSS, whose version 3.1 specification is maintained by FIRST and enriches entries in the NVD, the National Vulnerability Database that NIST maintains. The chain is short: fingerprint, match, score, and the output is a prioritized list of findings.

Three consequences fall out of understanding the machine. First, the scanner can only know what its database knows. A scanner with a stale plugin set, run against software released after the last update, will report a clean network that does not exist. Database currency is the scanner’s single most important operational requirement, and NIST SP 800-115 makes keeping tools current part of the discipline of testing. Second, the scanner’s match is probabilistic. Version fingerprints collide, configurations mislead, and services answer on unexpected ports, which is why scanners produce false positives and why the accepted practice, in NIST SP 800-115 and in every mature program, is manual verification: a human confirms the finding against the actual system before it becomes a ticket, and a re-scan confirms the fix after. Third, the scan is a snapshot in time. What it says is true of the moment it ran, and only that moment, which is why scanning is a continuous activity rather than a one-time event.

The credentialed question is the discriminator the exam uses most in this area. An uncredentialed scan looks at the system from outside its trust boundary, the way an unauthenticated attacker would, and sees what the network reveals. A credentialed scan logs in with a legitimate account and reads configuration truth: patch levels, registry values, file versions, service settings, the things a banner can never reveal. The two answer different questions, and the mature program runs both, because each misses what the other sees. NIST SP 800-53 Rev. 5 institutionalizes the activity in control RA-5, “Vulnerability Monitoring and Scanning,” which requires the organization to scan for vulnerabilities in its systems and hosted applications, keep the scanning tools interoperable and their updates automated, and act on the findings. The same catalog puts the other instruments into their own controls: CA-2 for security assessments, CA-7 for continuous monitoring, and CA-8 for penetration testing. If a question asks which control owns regular vulnerability scanning, RA-5 is the name.

The continuous layer deserves its own sentence because the exam treats it as the mature end state. NIST SP 800-137, “Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations,” defines continuous monitoring as maintaining ongoing awareness of information security, vulnerabilities, and threats to support risk management decisions, which is a different animal from a quarterly scan. The continuous program keeps a risk picture that is always reasonably current, scans on a rhythm that matches the environment’s change rate, and re-scans on events, a new version, a new perimeter, a new cloud tenant, rather than waiting for the calendar. NIST SP 800-40 Rev. 4, the enterprise patch management planning guide, supplies the remediation half: the organization decides how it will learn about vulnerabilities, prioritize them, test patches, deploy them, and verify deployment, and the scanner’s output is the fuel for that machine. The standard-setting echo comes from ISO/IEC 27001:2022 Annex A control 8.8, “Management of technical vulnerabilities,” which requires the organization to obtain information about technical vulnerabilities in a timely manner, evaluate its exposure to them, and take appropriate measures, which is the same loop expressed as a management-system requirement.

Standardized checks and the baseline: SCAP

Vulnerability scanning answers “what is known to be weak.” A different instrument answers “does this match the baseline we chose,” and its name is SCAP, the Security Content Automation Protocol, whose technical specification lives in NIST SP 800-126 Rev. 3. SCAP is not a single tool. It is a family of interoperable formats that let machines express security checks and exchange results: XCCDF for checklists and policy language, OVAL for the low-level tests that check a specific state on a system, CPE for naming the platforms a check applies to, with CVE and CVSS supplying the vulnerability vocabulary. The value proposition is portability: a baseline written once as SCAP content can run across tools and vendors, which is exactly what makes it the natural engine for configuration reviews and for the compliance comparisons the audit side of the domain needs.

The exam’s SCAP questions are almost never about the acronym soup. They are about what the protocol is for: turning a security requirement into a machine-checkable statement, and proving conformance with evidence rather than with testimony. When a scenario describes an organization that must demonstrate, across hundreds of identical servers, that each one is patched and hardened to the same standard, the SCAP answer is the one that scales, because the check is expressed once and executed everywhere. The configuration review itself, comparing systems against a vendor hardening guide or an internal standard, is the human activity the SCAP machinery automates, and the output, a conformance report listing each check and its result, is evidence in exactly the sense this chapter’s first section defined.

Application instruments: SAST, DAST, IAST, and fuzzing

The application bench has more moving parts than the network bench, and the exam wants you to know which instrument sees what. Static application security testing, SAST, analyzes source code or bytecode without executing it. It is a reading instrument: it follows the data flow, checks rules against patterns, and reports where the code could be vulnerable, with the crucial caveat that it has never run the code and therefore cannot say what the code actually does at runtime. Its strength is placement, it can run on every commit, before anything is built, when a fix is cheapest, and its weakness is noise: static analyzers produce false positives that someone must triage. Dynamic application security testing, DAST, is the outside caller: it probes a running application through its interfaces, submitting requests and observing responses, the way an attacker would, which means it sees the deployed truth and only what it can reach. Interactive application security testing, IAST, instruments the application itself and observes behavior from inside, combining the code view and the runtime view. Runtime application self-protection, RASP, leaves the assessment bench entirely and sits inside the application to block attacks in flight, which is a control, not a test, and the exam will make you tell the difference.

The methodology for web application testing is public and standard. OWASP maintains the Web Security Testing Guide, WSTG, whose version 4.2 is the current edition, a catalog of test cases organized by function, authentication, authorization, session management, input validation, and the rest, each with expected results and evidence guidance. OWASP also publishes the Application Security Verification Standard, ASVS 4.0, which defines verification levels so that a buyer can specify how deep the testing must go, level 1 for the minimum acceptable, level 2 for most applications that handle sensitive data, level 3 for the highest-value targets, and this matters to the manager because it turns “test the application” into a contract term with a defined depth. The tools that execute the methodology are the proxy-based DAST instruments: Burp Suite, the commercial tool with a free community edition, and OWASP ZAP, the open-source project, both of which intercept traffic between browser and application, replay requests, spider the site, and run active checks. Their evidence product is the request and response pair: the exact input, the exact output, the proof of the behavior the finding describes.

Fuzzing is the instrument that answers a question no scanner can: does this code survive input it was never designed for? A fuzzer generates inputs and feeds them to the target, watching for crashes, hangs, assertion failures, and memory errors. The two classic families are mutation fuzzing, which takes valid inputs and perturbs them, and generation-based or grammar-based fuzzing, which builds inputs from a model of the expected format. The modern practice is coverage-guided fuzzing, embodied in open-source engines such as libFuzzer, part of the LLVM toolchain, and AFL, the American Fuzzy Lop project: the fuzzer instruments the code to measure which branches each input reaches, keeps the inputs that open new paths, and mutates those preferentially, which makes the campaign explore the program instead of bouncing off the same wall. Fuzzing’s product is the crash reproduction: a saved input, the build it crashed on, and a stack trace, which is evidence of robustness failure, not yet evidence of exploitability. The exam will ask you to hold that distinction: a fuzzer found a crash, and the question is what has been proven, and the answer is that a robustness defect has been demonstrated, while whether it can be exploited is a separate question for the exploitation bench.

Exploitation and credential instruments

The exploitation framework is where the assessment stops being a reading exercise and starts behaving like the adversary. The best-known open-source example is the Metasploit Framework, which organizes exploits, auxiliary modules, payloads, and post-exploitation modules into one console. A framework question in the exam is almost never about a specific module. It is about what the framework proves: that a weakness is not merely present but reachable, that the demonstrated path from initial access to impact is real, and that the organization should act as if it has been owned. The proof product is the session, the live access the tester holds, plus the narrative of how it was obtained, which is exactly the “demonstrated consequence” the strategy chapter said converts a finding into a business decision.

Specialized tools answer specialized questions. sqlmap is the open-source tool that automates the detection and exploitation of SQL injection, the classic case where an input validation flaw becomes a database read. Its evidence product is the proof of the injection point: the payload that worked, the response that revealed it, and, in the worst case, the data that came out, which is the moment a technical weakness becomes a data-breach narrative. The automation point matters: a tool like sqlmap can test thousands of parameter combinations in the time a human would spend on one, which is why the exam pairs it with scenarios about scale and about the damage a single unpatched injection point can do.

The credential bench has two sides, and the exam separates them carefully. Offline attacks work against captured material, a stolen password hash, a dump, a compromised authentication database, and the attacker is free to compute without limit, trying candidate passwords against the hash until one fits. The instruments are hashcat, the GPU-accelerated password recovery tool, and John the Ripper, the long-standing open-source cracker, and they implement the standard attack families: dictionary attacks against wordlists, rule-based attacks that mangle dictionary entries, mask attacks that enumerate patterns like eight lowercase letters plus a digit, and pure brute force for short secrets. The evidence product is the recovery statistics: how many hashes fell to which attack family, how fast, and at what point the campaign stopped being profitable. That evidence is why password policy is a security question and not an administrative one. NIST SP 800-63B, the authentication guidance, directs the modern answer: memorized secrets should be long, at least eight characters with a recommended minimum of fifteen, should be checked against lists of known breached passwords rather than subjected to composition rules, and should never be reused across systems, because the offline attacker is exactly the threat model those rules are built to defeat. Online attacks, by contrast, run against the live service, one guess per network request, and they are shaped by the service’s controls: account lockout, rate limiting, and anomaly detection. Password spraying, trying one common password across many accounts, exists precisely to stay under the thresholds those controls enforce, and the exam uses it to test whether you understand why an attacker would trade breadth for volume.

Wireless and mobile instruments

The wireless bench exists because the radio spectrum is the one network boundary that cannot be locked in a closet. The Aircrack-ng suite is the standard open-source collection, and its pieces teach the wireless methodology: airodump-ng captures traffic and identifies access points and clients, aireplay-ng injects frames to force the activity a test needs, and aircrack-ng performs the offline recovery work on the captured material. The exam’s wireless questions cluster around one finding, the captured WPA handshake, the four-way exchange that proves a client knows the passphrase, because once an attacker has captured that handshake, the passphrase becomes an offline dictionary problem: try passphrases against the captured exchange until one fits, with no limit on attempts and no lockout. The evidence product is the handshake capture plus the recovery result, and the security consequence is that a weak, short, or dictionary-word passphrase on the wireless network is not protected by the impossibility of eavesdropping, because the eavesdrop is the easy part and the dictionary is the whole game.

The mobile bench answers a different set of questions about the apps the organization runs. Static analysis tools such as MobSF, the Mobile Security Framework, unpack the application and examine its code and configuration for the classic mobile findings: secrets embedded in the binary, insecure storage of data on the device, weak transport settings, and dangerous platform APIs. Dynamic instruments such as Frida, the runtime instrumentation toolkit, attach to the running app and observe or manipulate its behavior, which is how a tester demonstrates that a supposed client-side check can be bypassed, that a local authentication gate is decoration, or that data the app keeps “secure” on the device is in fact readable. The pairing of static and dynamic is the mobile version of SAST and DAST: the static pass finds what the code contains, the dynamic pass proves what the running app allows, and a mobile finding is only complete when both sides have spoken.

Evidence handling and the two-audience report

Every instrument on this bench produces the same deliverable, a report, and the report is where the whole purchase either pays off or does not. The discipline has two halves.

The first half is making each finding’s evidence strong enough to survive contact with the people who will question it. A finding that reaches a fixer needs reproduction steps: the exact requests, the exact commands, the tool and version, the environment it was reproduced in, the capture or screenshot, with sensitive data redacted. NIST SP 800-115’s reporting guidance asks for findings that carry evidence, impact, and remediation recommendations, and the habit that makes them trustworthy is the one from this chapter’s opening: each finding should state what was tested, what was observed, and why that observation means what the finding claims. Redaction deserves its own mention because it is the evidence error that creates incidents: screenshots of a dashboard full of production PII, captures that include credentials the scanner recovered, these turn the assessment itself into a data exposure, and the redaction pass is not optional polish but part of the handling.

The second half is the audience ladder. The fixers need technical depth. The decision-makers need risk language: what this weakness means for the business, what the demonstrated impact would be, what it costs to fix, and what it costs to defer. The same report, or the same findings summarized, serves both only if the author deliberately writes for each. The exam tests the ladder by describing a manager who receives a raw technical report and asks what to do, and the answer is never “hand it to the board” and never “ignore it,” it is translate, prioritize, and route: attach owners and due dates, tie severity to business context, and require verification that the fix landed. Severity is where CVSS earns its keep and where it has to be tempered: the base score describes the intrinsic properties of the weakness, and the environmental score, in the CVSS v3.1 model, adjusts it for the organization’s own context, which is the difference between a 9.8 in a lab and a 9.8 on a system that faces the internet and holds the payment data, a distinction the exam will absolutely make you draw.

Governing the bench

The bench needs governance, and the governance is mostly about three things. First, currency: every instrument that matches against external knowledge, scanners, signature databases, framework modules, is only as good as its last update, and the tool inventory should name an owner and an update cadence for each entry. Second, credentials: scanners and assessment agents run with accounts that can see a great deal, and those accounts are themselves sensitive assets, issued under least privilege, scoped to the assessment’s targets, and revoked when the assessment ends. Third, calibration: the bench should be proven against known-good targets from time to time, a deliberately vulnerable lab application, a staging network with known weaknesses, so that the team knows the instruments fire correctly and the false-positive baseline, and a scan that finds nothing on a deliberately broken target is a scan that needs its database updated, not a clean bill of health. NIST SP 800-137’s continuous monitoring strategy makes the same point at the program level: the metrics must be meaningful, and an instrument that cannot detect the change it exists to detect is worse than no instrument, because it produces confidence instead of evidence.

Hold the whole bench against the frame from the first section. Instruments produce claims. Evidence is claims with reproducibility, provenance, integrity, and coverage. Verification is the step that turns a claim into a finding, and the report is where a finding becomes a decision. The exam will hand you a tool, a technique, or a capture and ask what it proves, and the answer is always found by asking what the instrument actually measures, what it cannot see, and what would have to be true for its output to be wrong. That question, asked honestly, is the whole craft of this domain.

Practice questions

1. A security engineer needs to prove that a specific web application, running in production, can be manipulated by an external caller through its HTTP interface. The requirement is to see the deployed behavior, not the source code. Which instrument class fits?

   A. SAST B. DAST C. A fuzzer D. SCAP

2. An assessment team captures network traffic during an incident and later claims it can show exactly which data was stolen. The traffic is TLS 1.3 end to end. What is the strongest true statement about this claim?

   A. The capture proves the data, because TLS negotiation records the payload B. The capture proves only metadata, addresses, sizes, and timing, because the payload is encrypted C. The capture cannot prove anything, because packet capture never works against TLS D. The capture proves the data, because the certificate exchange reveals the plaintext

3. A vulnerability scanner reports a critical finding on every server in a fleet. The scanning engineer suspects the results are wrong. What is the correct next step?

   A. Accept the scan output as authoritative and deploy emergency patches B. Manually verify the finding against a sample of affected systems before acting C. Re-run the scan with the same tool to see if the result repeats D. Suppress the finding because scanners are known to be noisy

4. An organization must demonstrate that two hundred identical servers all match the same hardening baseline, with machine-readable evidence. Which approach produces that evidence at scale?

   A. A manual checklist signed by each administrator B. SCAP content that expresses the baseline as executable checks C. A penetration test of one representative server D. A packet capture of each server’s traffic

5. A tester captured a WPA handshake from a company wireless network and wants to determine whether the passphrase is weak. Which statement is correct?

   A. The handshake lets the tester try passphrases offline, with no per-attempt lockout B. The handshake is useless without the wireless controller’s logs C. The handshake proves the passphrase is secure, because WPA2 cannot be broken D. The handshake can only be tested with the access point online and rate-limited

6. A developer commits code, and the pipeline runs an analyzer that flags a possible SQL injection before the code is ever built. Which instrument is this, and what is its known weakness?

   A. DAST, which cannot see the code B. SAST, which produces false positives because it never runs the code C. IAST, which is too slow for pipelines D. Fuzzing, which only finds crashes

7. A fuzzing campaign against a file parser produces a crash after three days. What has been proven?

   A. That the parser is exploitable B. That the parser contains a robustness defect triggered by a specific input C. That the parser has no other defects D. That the parser must be rewritten

8. Which control in NIST SP 800-53 Rev. 5 is the one that institutionalizes regular vulnerability scanning of systems and hosted applications?

   A. CA-8 B. CA-7 C. RA-5 D. CA-2

9. An attacker captured password hashes from a compromised database and wants to test candidate passwords against them without limit. Which attack family does this represent?

   A. Online password spraying B. Offline password cracking C. A phishing campaign D. An SQL injection

10. An organization needs to know what an unauthenticated outsider can see of its network. The assessment must model that vantage point honestly. What should the scan design include?

    A. Credentialed scans from inside the perimeter B. Uncredentialed scans from outside the perimeter C. Packet captures of internal traffic D. A SAST review of the network management code

11. A scanner uses a plugin database that has not been updated in eleven months. What is the most important consequence for its results?

    A. The results will be slower but still correct B. The results will miss every weakness disclosed since the last update C. The results will be identical to a current scanner’s D. The results will be more accurate, because the plugins are stable

12. A test finding includes a screenshot of a production dashboard that contains customer PII, pasted directly into the report. What evidence-handling error occurred?

    A. The finding lacks a timestamp B. The finding lacks redaction and exposes sensitive data in the report C. The finding cannot be reproduced D. The finding has no severity score

13. Which pair of tools, one for capturing wireless traffic and one for the offline recovery work, belongs to the same open-source suite?

    A. airodump-ng and aircrack-ng B. tcpdump and Wireshark C. hashcat and John the Ripper D. MobSF and Frida

14. A red team needs to document, step by step, how it moved from initial access to the payment database, for the final report. Which tool class is most likely to produce that narrative evidence?

    A. A packet capture of the whole exercise B. An exploitation framework, whose sessions and modules record the path C. A vulnerability scanner D. A configuration review

15. A web application’s authentication is handled by the server, and the client keeps a session token. A tester wants to check whether the session token can be guessed or stolen. Which methodology document catalogs the relevant test cases?

    A. The OWASP Web Security Testing Guide B. CVSS v3.1 C. NIST SP 800-126 D. The ISC2 Code of Ethics

16. A scan found a weakness that scores 9.4 in CVSS v3.1 on a system that is isolated, holds no sensitive data, and is not reachable from the internet. What does the environmental assessment add to this picture?

    A. The base score is the only score, and 9.4 is final B. The environmental score adjusts the base score for the organization’s context, which can lower the effective risk C. The environmental score always raises the base score D. CVSS cannot be applied to isolated systems

17. A manager is handed a fifty-page raw scan export and asked what to do with it. What is the correct first move?

    A. Forward it to the board, because it is thorough B. File it, because scan exports are not actionable C. Verify the highest-priority findings, translate them into risk language, and route each to an owner with a due date D. Delete the false positives and print the rest

18. Which statement correctly describes the relationship between an uncredentialed scan and a credentialed scan?

    A. The credentialed scan reads configuration truth with a legitimate account; the uncredentialed scan sees only what the network reveals B. The uncredentialed scan is always more accurate because it models the attacker C. The two scans are interchangeable D. Credentialed scans are prohibited by NIST SP 800-53

19. A mobile app stores a customer’s data in local storage, and the tester wants to prove whether a local authentication gate can be bypassed at runtime. Which instrument fits?

    A. A network vulnerability scanner B. A runtime instrumentation tool such as Frida C. A SCAP check D. A port scanner

20. An organization’s ISO/IEC 27001:2022 management system requires the organization to obtain timely information about technical vulnerabilities, evaluate its exposure, and take appropriate measures. Which Annex A control states this requirement?

    A. Annex A 8.8, “Management of technical vulnerabilities” B. Annex A 6.8, “Reporting information security events” C. Annex A 5.15, “Access control” D. Annex A 8.24, “Use of cryptography”

Answers and rationales

1. B. DAST probes a running application through its interfaces and observes the deployed behavior, which is exactly what the requirement specifies. SAST analyzes code without running it (option A), fuzzing attacks input robustness rather than application functions (option C), and SCAP checks configuration baselines (option D).

2. B. A capture of TLS 1.3 traffic sees metadata, addresses, port numbers, packet sizes, and timing, while the payload stays encrypted, so the claim that the exact stolen data is visible is unsupported without a decryption story. TLS negotiation does not reveal the payload (option A), captures work fine against TLS (option C), and certificates prove identity, not plaintext content (option D).

3. B. Scans produce claims, and the accepted practice, reflected in NIST SP 800-115, is manual verification of findings against the actual systems before they become actions. Deploying emergency patches on unverified scan output (option A) is how false positives become incidents, re-running the identical scan (option C) only repeats the same claim, and suppression (option D) discards evidence instead of resolving it.

4. B. SCAP, per NIST SP 800-126 Rev. 3, expresses security checks in interoperable formats such as XCCDF and OVAL so a baseline runs identically across systems and produces machine-readable conformance results. Manual checklists do not scale (option A), a penetration test of one server tests exploitability, not fleet conformance (option C), and packet captures cannot check configuration baselines (option D).

5. A. The captured handshake moves the passphrase problem offline, where the tester can try candidates with no lockout or rate limit, which is why weak wireless passphrases are so dangerous. The controller’s logs are irrelevant to offline recovery (option B), WPA2 handshakes are absolutely breakable when the passphrase is weak (option C), and offline testing does not need the access point online (option D).

6. B. Analyzing source before it runs is SAST, and its known tradeoff is noise, false positives from pattern matching without runtime truth. DAST runs the application (option A), IAST instruments the running app and is not the described pipeline stage (option C), and fuzzing is an input-robustness instrument, not a source analyzer (option D).

7. B. A fuzzer’s crash reproduction demonstrates a robustness defect for a specific input, which is evidence of a defect, not of exploitability, not of cleanliness. Exploitability is a separate question for the exploitation bench (option A), one crash says nothing about other defects (option C), and rewriting is a decision, not a proven necessity (option D).

8. C. RA-5, “Vulnerability Monitoring and Scanning,” requires scanning for vulnerabilities in systems and hosted applications. CA-8 is penetration testing (option A), CA-7 is continuous monitoring (option B), and CA-2 is security assessments (option D).

9. B. Working against captured hashes with unlimited computation is offline password cracking, the attack family that hashcat and John the Ripper support. Password spraying is an online attack shaped by lockout (option A), phishing obtains credentials by deception (option C), and SQL injection reads databases, it does not crack captured hashes (option D).

10. B. To model an unauthenticated outsider honestly, the scan must run uncredentialed and from outside the perimeter, the vantage point such an attacker holds. Credentialed internal scans see inside truth (option A), captures show traffic, not exposure (option C), and SAST reviews code, not network exposure (option D).

11. B. The scanner can only match what its database knows, so an eleven-month-old plugin set misses every weakness disclosed since the update, which can make a vulnerable network look clean. The other options misunderstand the matching mechanism: currency, not speed (option A), determines correctness, results cannot match a current database (option C), and staleness never improves accuracy (option D).

12. B. Evidence handling includes redaction, and pasting a production dashboard full of PII into a report turns the assessment itself into a data exposure. The other options describe real evidence-quality concerns but none is the error in the scenario: the screenshot may well have timestamps (option A), may be reproducible (option C), and may carry a severity (option D), and none of that fixes the leak.

13. A. airodump-ng and aircrack-ng are both part of the Aircrack-ng wireless suite, the former for capture and the latter for offline recovery. tcpdump and Wireshark are a capture and an analyzer but not the wireless suite (option B), hashcat and John the Ripper are credential tools (option C), and MobSF and Frida are mobile instruments (option D).

14. B. An exploitation framework records modules, sessions, and the steps of the attack, which is the natural raw material for a chain-of-attack narrative. A packet capture of the whole exercise would be enormous and encrypted (option A), a scanner produces findings, not paths (option C), and a configuration review checks baselines (option D).

15. A. The OWASP Web Security Testing Guide, WSTG 4.2, catalogs test cases for session management, including token handling, alongside the other functional areas. CVSS v3.1 is a scoring model (option B), SP 800-126 is SCAP (option C), and the Code of Ethics is not a testing methodology (option D).

16. B. CVSS v3.1 includes an environmental score that adjusts the base score for the organization’s context, and an isolated system with no sensitive data can have a materially lower effective score. The base score is not final by itself (option A), environmental adjustment can move the score in either direction (option C), and CVSS applies to isolated systems (option D).

17. C. The manager’s discipline is verification, translation, and routing: confirm the high-priority findings, express them in risk language for decision-makers, and attach owners and due dates. Raw exports are not board material (option A), ignoring the report wastes the purchase (option B), and deleting findings without verification is how gaps stay open (option D).

18. A. The credentialed scan logs in and reads configuration truth; the uncredentialed scan sees only what the network reveals, and the mature program runs both because each misses what the other sees. Uncredentialed scans are not inherently more accurate (option B), the two are not interchangeable (option C), and credentialed scanning is not prohibited (option D).

19. B. Runtime instrumentation such as Frida attaches to the running app and can demonstrate whether a client-side gate is real or decorative. A network scanner cannot see inside the app (option A), SCAP checks baselines (option C), and a port scanner maps exposure (option D).

20. A. ISO/IEC 27001:2022 Annex A control 8.8, “Management of technical vulnerabilities,” requires timely vulnerability information, exposure evaluation, and appropriate measures. The other listed controls govern reporting weaknesses (option B), access control (option C), and cryptography (option D), which are not the requirement described.

Security testing tools on one page

Hold the bench as a pipeline and every question in this chapter answers itself. Discovery maps what exists, capture records what crossed the wire, the vulnerability scanner matches fingerprints against the CVE and NVD knowledge base and scores them with CVSS v3.1, SCAP checks baselines at scale, SAST reads code before it runs, DAST probes the running application, fuzzing finds the inputs that break robustness, the exploitation framework proves which weakness becomes access, and the credential bench measures how weak the passwords are.

The properties of evidence are the yardstick: reproducible, with provenance, verified integrity, and complete coverage. A scan result is a claim until a human verifies it, and a report finding is a decision only when it carries reproduction steps, risk language, and an owner with a due date. The instrument’s database must be current or the clean result is a lie. The credentialed scan and the uncredentialed scan answer different questions. The fuzzer crash is a defect, not an exploit. The captured WPA handshake is an offline dictionary problem. The encrypted capture is metadata and timing, never content, unless a decryption design explains how.

The controls and standards that anchor the whole bench: RA-5 for scanning, CA-2 for assessment, CA-7 for continuous monitoring, and CA-8 for penetration testing in NIST SP 800-53 Rev. 5, with SP 800-115 as the methodology, SP 800-137 as the continuous-monitoring frame, SP 800-40 Rev. 4 as the patch-planning partner, and ISO/IEC 27001:2022 Annex A 8.8 as the management-system requirement. And the one habit to carry into the Domain 6 practice test: when a question describes a tool, ask what the instrument measures, what it cannot see, and what would have to be true for its output to be wrong. The answer to the question is in the honesty of the instrument, not in its name.