Chapter 3: Vulnerability Discovery and Analysis

A penetration test lives or dies on the quality of its discovery phase. Exploitation gets the attention, but

exploitation without disciplined discovery is guessing: you fire exploits at whatever responds, miss the real

weaknesses, and report noise that the client cannot act on. Vulnerability discovery is the craft of finding

weaknesses systematically, proving which ones are real, and ranking them so the exploitation phase spends its

limited time on the findings that actually lead somewhere. The exam tests this as judgment, not as tool trivia.

You will be given scan output, a half-finished assessment, or a finding that looks critical and asked what to do

next. The right answer is almost always the disciplined one: verify before you claim, read the evidence before

you rank, and understand what your tools can and cannot see.

1. Vulnerability scanning types

Scanning is not one activity. The scan type you choose decides what you can see, how much you can trust the

results, and what you might break. A penetration tester picks scan types the way a doctor picks tests: matched

to the question being asked, with full awareness of each method's blind spots.

1.1 Credentialed vs non-credentialed scans

A non-credentialed scan talks to a target from the outside, the way an unauthenticated attacker would. It probes

ports, reads banners, and infers software versions from what the target volunteers. It is safe, easy to arrange,

and realistic for the external attacker's view. Its weakness is inference: banners lie. Vendors backport security

fixes without changing version banners, custom builds report misleading versions, and a service can be

configured to hide its version entirely. A non-credentialed scan reports what the target claims to be, not what it

is.

A credentialed scan logs in with valid credentials and inspects the system directly: installed packages and patch

levels, registry or configuration values, running services, local security policy. It sees the truth instead of the

advertisement, which makes it far more accurate and far better at confirming that a patch is actually present.

The cost is access: somebody must provision credentials, manage them securely, and grant the scanner enough

privilege to read system state without handing it the keys to the kingdom. Credentialed scanning also changes

the trust picture: the scan account itself becomes a privileged credential that must be protected, rotated, and

removed when the assessment ends.

Figure 10: Credentialed vs non-credentialed scan - what each method sees on the same target, and where banner-based errors come from

(illustrated)

1.2 Agent-based vs agentless scanning

Agent-based scanning installs a small agent on each host. The agent collects vulnerability data locally and

continuously, reports back on a schedule, and keeps working when the host is off the corporate network, which

is exactly when laptops accumulate unpatched software. Agents give you coverage of roaming and remote

machines and reduce the blast of network traffic that a scan window creates. Their costs are deployment and

maintenance: somebody installs the agent everywhere, updates it, and troubleshoots the hosts where it stops

reporting.

Agentless scanning needs no software on the target. The scanner reaches out over the network, authenticates,

and inspects remotely. It is simpler to start and leaves no footprint on the host, but it only sees hosts that are

reachable during the scan window, it generates more network traffic, and it depends entirely on network access

and working credentials at scan time. A laptop that is powered off during the window is simply not assessed.

1.3 Network, web, and cloud scans

Network scans map hosts, ports, and services, then match what they find against vulnerability signatures. They

answer the infrastructure question: what is exposed, and what known flaws does it carry? Web scans go deeper

on one application: they crawl the site, map its pages and parameters, and test inputs for web flaws such as

injection and cross-site scripting. A web scan that cannot authenticate, handle session tokens, or reach pages

behind multi-step workflows will miss the application's most important surfaces. Cloud scans do not probe ports

at all in the traditional sense; they call provider APIs and read configurations, comparing them against

benchmarks. A cloud scan answers the configuration question: which buckets are public, which security groups

are open, which identities are over-privileged?

A tester at CertCrack.com planning an assessment of the company's public storefront would run all three, in

order: a network scan to map the exposed estate, a web scan of the storefront application itself with

authenticated sessions, and a cloud configuration review of the account hosting it. Each scan type answers a

question the others cannot ask.

2. SAST and DAST

Static and dynamic testing see different halves of an application. Confusing them is one of the exam's favorite

traps, because their names sound similar and their outputs look similar, but they find different flaws at different

times.

2.1 SAST: reading code without running it

Static application security testing (SAST) analyzes source code, bytecode, or binaries without executing the

program. It traces data flow from untrusted inputs (sources) to dangerous operations (sinks) and flags patterns

that look like injection, insecure cryptography, hardcoded secrets, or unsafe deserialization. SAST runs early, in

the development pipeline, before the code ever reaches a running environment. It finds flaws developers can fix

while the code is still in front of them, and it sees code paths that a running test might never reach, including

error handlers and rarely used branches.

SAST's weakness is that it reasons about code, not behavior. It flags patterns that look dangerous but are safe in

context, because a validation routine elsewhere neutralizes the input. It also misses flaws that only exist at

runtime: configuration mistakes, authentication logic that depends on deployment settings, and business-logic

flaws that no pattern can express. A SAST report is a list of candidates, and every candidate needs a human to

decide whether it is real.

2.2 DAST: attacking the running application

Dynamic application security testing (DAST) tests the running application the way an attacker would: it sends

requests, observes responses, and looks for evidence of flaws. It finds what SAST cannot see, because it sees the

application as deployed, with its real configuration, real authentication, and real data handling. A DAST finding

comes with proof in the form of a request and a response, which makes it easier to confirm and harder to

dismiss.

DAST's weakness is coverage. It can only test what it can reach. Pages behind authentication, multi-step

workflows, and single-page application states that the crawler never triggers are invisible to it. And DAST checks

range from safe to intrusive: a safe check reads banners and error messages, while an intrusive check sends

payloads that attempt injection, manipulate parameters, or trigger error conditions. Intrusive checks can modify

data, lock accounts, or disrupt a service, which is why they belong only in agreed test windows against

non-production targets or explicitly authorized production systems, never as a surprise against a live service.

2.3 Pipeline placement and crawl gaps

SAST belongs early in the pipeline, on every commit or pull request, where its findings are cheapest to fix and its

false positives cost a developer minutes rather than an incident. DAST belongs later, against a deployed test

environment, on a schedule or before release, where it validates the assembled application. A mature program

runs both, because each covers the other's blind spots, and adds software composition analysis for third-party

libraries, which neither SAST nor DAST evaluates well.

Crawl gaps are DAST's most important limitation and the exam's favorite DAST trap. A crawler that never logs in

tests only the public surface. A crawler that cannot handle JavaScript-heavy pages misses the application's real

functionality. A crawler that never completes a multi-step checkout or form workflow never tests the code

behind those steps. When a DAST report comes back clean, the first question is not whether the application is

secure but whether the crawler saw the application. Coverage first, verdict second.

Figure 11: SAST vs DAST pipeline placement - where each method runs, what it sees, and where crawl gaps hide (illustrated)

3. Scan configuration and troubleshooting

A scan that fails silently is worse than a scan that fails loudly, because it produces a report that looks complete

while covering nothing. Most scan troubleshooting is about one question: did the scanner actually see and

assess what you think it assessed? Work through failures in order, from discovery to authentication to network

path to scope.

3.1 Discovery failures and scope

Discovery is the step where the scanner finds live hosts. It fails quietly more than any other step. ICMP echo is

commonly blocked, so a scanner that relies on ping to decide a host is alive will mark live hosts as dead and skip

them. DNS records go stale, so a scanner can probe an address that now belongs to a different host or to

nothing at all. DHCP reassigns addresses between the asset inventory and the scan, so the host you think you

scanned may be a different machine by scan time. And scope mistakes cut both ways: too narrow a scope

misses assets, while too broad a scope scans systems outside the authorization, which is both a reporting failure

and a professional one.

The fix is to verify discovery independently of the scanner's own claims. Compare the hosts the scanner reports

as alive against the asset inventory and the DHCP lease records for the scan window. If a critical host is missing

from the results, do not assume it is clean; assume it was never assessed, and find out why. A report that cannot

account for every in-scope asset is incomplete, and the tester says so in plain language rather than letting a

clean-looking report imply coverage that never happened.

3.2 Authentication failures

Authentication failures are the most common reason scan quality collapses, and the most common reason is

mundane: expired passwords, rotated service account credentials, accounts locked by too many login attempts,

or privilege escalation that works on some hosts and fails on others. The symptom is a report that looks normal

but is thin: fewer findings than expected, findings that read like banner guesses, and an authentication

summary showing a low success rate. The danger is that nobody reads the summary. The findings get reported,

the coverage gap does not, and the client believes an estate was assessed that was only skimmed.

When authentication fails, stop and fix it before interpreting findings. Confirm the scan account is valid,

unlocked, and has the privilege the scanner needs on a sample host. Check the escalation path separately from

the login: a scanner can log in successfully and still fail to read patch state if its privilege escalation to

administrator or root fails. Re-run the failed hosts after the fix, and report the original coverage gap honestly:

the first run assessed only the authenticated portion, and the second run closed the gap.

3.3 Firewall blocks, windows, and DHCP correlation

Firewalls and intrusion prevention systems treat scanners the way they treat attackers, because from the

network's view there is no difference. A scanner's rapid probes trip rate limits, its payloads match intrusion

signatures, and its traffic gets dropped or shunned mid-scan. The result is a report full of hosts that appear

down or ports that appear filtered, when the real story is that the scanner's traffic never arrived. The fix is

coordination, not force: agree on scan windows, whitelist the scanner's source address on the path to the

targets, and confirm with the network team that the scan traffic is expected. If whitelisting is refused, say so in

the report and describe what the blocking cost in coverage.

Scan windows create their own failures. A scan that overruns its window gets cut off mid-assessment, leaving

part of the estate unscanned, or it keeps running into business hours and disrupts production traffic. Estimate

honestly: large estates, slow links, and intrusive checks all stretch scan time. Break the work into windows that

fit, and track completion per window rather than assuming the whole estate was covered.

DHCP correlation is the quiet bookkeeping that makes results trustworthy. When addresses change between

discovery and scanning, or between scanning and reporting, findings attach to the wrong host. Correlate scan

results with DHCP lease records and asset inventory by time: which host held this address during the scan

window? A finding reported against the wrong host wastes remediation effort and, worse, lets the truly

vulnerable host go unpatched.

Troubleshooting a failed or thin scan, step by step:

1. Confirm discovery: compare hosts found against the asset inventory and DHCP leases for the scan

window, and account for every missing host.

2. Check authentication: read the authentication summary first, verify the scan account on a sample host,

and fix login and privilege escalation failures before interpreting findings.

3. Check the network path: confirm the scanner's traffic is not being dropped, rate-limited, or shunned by

firewalls or intrusion prevention on the way to the targets.

4. Check scope and window: confirm the scan covered exactly the authorized scope and finished inside its

window, and re-run anything cut off or left out.

5. Correlate results by time: match findings to hosts using DHCP and inventory records from the scan

window, not from today, so findings attach to the right machines.

4. Reading scanner output

Scanner output is not a verdict. It is evidence, and evidence has to be read with attention to what produced it,

how confident the scanner is, and what the scanner could not see. The three scanners below illustrate the range:

each reports differently, and each has characteristic errors.

4.1 Nessus: plugins and evidence

Nessus organizes its knowledge as plugins: each plugin tests for one vulnerability, misconfiguration, or

information disclosure, and carries a severity derived from CVSS plus Tenable's own vulnerability priority rating.

A Nessus result names the host, the plugin, the severity, and the evidence the plugin observed, followed by a

solution, usually a patch or configuration change. The analyst's job is to read the evidence, not just the severity.

A plugin that reports based on a banner is weaker evidence than the same plugin reporting from a credentialed

check that read the installed package version. A plugin that reports a service as present because a port

responded is weaker still.

Nessus output also includes informational plugins that are not vulnerabilities at all: operating system

identification, open ports, traceroute data, authentication success or failure. Those informational results are

where coverage is verified. An analyst who reads findings before reading the informational plugins is reading

conclusions before checking whether the assessment happened.

4.2 OpenVAS: QoD and results

OpenVAS, the scanner behind Greenbone, reports each finding with a Quality of Detection (QoD) value: a

percentage expressing how confident the scanner is in the result. A QoD of 100 percent means the finding was

confirmed by a reliable method, such as a credentialed package check. A QoD of 70 percent typically means

banner-based detection, which carries the usual banner risk. Lower values mean weaker evidence, such as a

check that inferred a flaw from a generic behavior. QoD is the scanner telling you how much to trust each line,

and the analyst who ignores it treats a guess and a confirmation as equals.

OpenVAS results also carry severities, solutions, and references to advisories, and its reports separate

vulnerabilities from informational results. The reading discipline is the same as with Nessus: check coverage and

authentication first, weigh each finding by its evidence quality, and treat low-QoD banner findings as candidates

for manual validation rather than confirmed vulnerabilities.

4.3 Nikto: web server checks

Nikto is a web server scanner, not a general vulnerability scanner. It probes a web server for dangerous files and

directories, outdated server software, misconfigurations, insecure headers, and known issues in common server

software, reporting each item with a reference identifier. Its output is a list of observations about the server, not

a verdict about the application: a missing security header is a hardening note, an outdated server version is a

lead, and a discovered backup file is a finding that needs manual confirmation.

Nikto's characteristic error is the error-page false positive. Many servers return a custom error page with a 200

OK status for missing files, so Nikto's request for a known dangerous file receives a normal-looking response,

and its signature matches the error page content rather than the file itself. The analyst confirms Nikto findings

by requesting the item manually and reading the actual response: is this the dangerous file, or the server's

polite apology for not having it?

5. Validating findings: false positives and false negatives

Validation is the step that separates a penetration test from a scan dump. A scanner reports possibilities; the

tester proves which ones are real, documents the proof, and carries only the proven findings into exploitation

and reporting. Skipping validation does not save time. It spends the client's remediation budget on ghosts and

spends the tester's credibility with it.

5.1 Banner-based false positives

The banner-based false positive is the most common validation story in the field, and it has one root cause: the

scanner trusts what the target claims about itself. A vendor backports a security fix into an older version without

changing the version banner, so the banner still advertises the vulnerable version. A custom build reports a

generic version string. A load balancer answers with the version of a different component than the one behind

it. In each case the scanner matches its signature to the banner and reports a vulnerability that is not present.

The validation is straightforward and must be done before the finding is reported: confirm the installed version

or configuration directly, through a credentialed check, a package query, or a behavior test that distinguishes

the vulnerable version from the patched one. If the direct check shows the fix present, the finding is a false

positive. Record it as such, with the evidence, because the same banner will trigger the same finding on the next

scan, and the next analyst deserves to know it was already settled.

5.2 Error-page signature matches and stale data

Error-page matches are the web equivalent of banner errors. A scanner requests a known dangerous file, the

server answers with a custom error page and a success status, and the scanner's signature matches text on the

error page rather than the file. The validation is manual and quick: request the item yourself, read the response,

and ask whether this is the file or the apology. The same discipline applies to stale data: a scan report from last

month describes last month's estate. Hosts have been rebuilt, addresses reassigned, and patches applied since.

A finding is only as current as its scan, and a finding carried forward without revalidation is a rumor, not a result.

5.3 The validation procedure

Validation is a procedure, not an instinct. Run it the same way for every finding worth reporting, so nothing gets

confirmed by enthusiasm and nothing gets dismissed by fatigue.

1. Reproduce the finding yourself, outside the scanner, using the evidence the scanner recorded: the host,

the port, the request, the version it claims.

2. Examine the evidence for its strength: credentialed confirmation, banner inference, error-page match, or

generic signature, and weigh the finding accordingly.

3. Confirm the version or configuration directly: a package query, a configuration read, or a behavior test

that separates the vulnerable state from the patched state.

4. Test safely and within authorization: use non-destructive checks, avoid payloads that modify data or

disrupt services, and stop at proof of the flaw rather than pushing into exploitation.

5. Document the verdict with evidence: confirmed, false positive with the disproving evidence, or

inconclusive with the reason and the next step needed. An undocumented dismissal is a finding waiting to

recur.

Figure 12: Finding validation workflow - from scanner report through reproduction, evidence check, direct confirmation, and documented

verdict (illustrated)

6. CVSS and EPSS

Scoring exists so that findings can be compared and sorted, but a score is a model, not a measurement. The

tester who understands what a score includes, and what it leaves out, ranks findings well. The tester who sorts

by score alone ranks them badly and confidently.

6.1 Base, temporal, and environmental metrics

The Common Vulnerability Scoring System (CVSS) rates severity from 0.0 to 10.0 using three metric groups. Base

metrics describe the flaw itself, independent of time and organization: attack vector (network, adjacent, local, or

physical), attack complexity, privileges required, user interaction, scope, and the impact on confidentiality,

integrity, and availability. Base metrics do not change unless the flaw itself changes. Temporal metrics describe

factors that change over time: exploit code maturity (from unproven to functional to weaponized), remediation

level (from no fix to official fix available), and report confidence. A flaw with public exploit code scores higher

temporally than the same flaw with no known exploit. Environmental metrics let an organization adjust the

score for its own reality: modified base metrics for its environment, and confidentiality, integrity, and availability

requirements reflecting how much the affected asset matters. Two organizations with the same flaw can

legitimately arrive at different environmental scores, because the same flaw on a test server and on a payment

database is not the same risk.

6.2 Scope and severity bands

Scope answers one question: does exploiting this flaw affect a security authority beyond the vulnerable

component? If scope is unchanged, the impact stays within the component that holds the flaw. If scope is

changed, exploitation escapes into another authority, for example a sandbox escape that reaches the host, or a

vulnerability in a virtual machine that affects the hypervisor. Changed scope raises the score substantially,

because the blast radius is larger than the component itself. The exam tests scope with escape scenarios: a flaw

that stays inside its container is one score, and the same flaw breaking out of the container is a higher one.

The qualitative severity bands for the base score are: None (0.0), Low (0.1 to 3.9), Medium (4.0 to 6.9), High (7.0

to 8.9), and Critical (9.0 to 10.0). Bands are labels for communication, not decisions. A High and a Critical can sit

in either priority order once context is applied, which is why the next section matters more than the bands

themselves.

6.3 Severity vs risk, and EPSS

Severity is not risk. A CVSS 9.8 flaw on an isolated system with no network path and no sensitive data may be

less urgent than a CVSS 6.5 flaw on an internet-facing server holding customer records, especially when exploit

code for the 6.5 is circulating. Risk adds what severity omits: exposure (can an attacker reach it?), exploit

availability (does working exploit code exist?), asset value (what does it protect?), and threat activity (is anyone

actually exploiting it?). Sorting a remediation queue by CVSS descending is the beginner's answer, and it is

usually wrong.

The Exploit Prediction Scoring System (EPSS) helps with one piece of that gap: it estimates the probability that a

vulnerability will be exploited in the wild in the next 30 days, expressed as a score from 0 to 1, often read

alongside its percentile rank among all vulnerabilities. A high EPSS score means exploitation is likely soon, even

if the CVSS score is moderate. Used together, the two scores answer different questions: CVSS says how bad the

flaw is, EPSS says how likely someone is to use it. A moderate CVSS with a high EPSS on an internet-facing asset

is a finding that jumps the queue, and the exam tests exactly that combination.

Figure 13: CVSS metric groups and severity bands - base, temporal, and environmental metrics feeding the score, with EPSS as the

exploitation-likelihood overlay (illustrated)

7. Manual validation techniques

Scanners find candidates. Manual validation proves them. The techniques below are the tester's confirmation

toolkit, and each one has the same discipline: use the smallest proof that settles the question, never a payload

that damages data or disrupts a service, and stay strictly inside the authorized scope. Every technique here is

described for use against your own lab systems or explicitly authorized targets.

7.1 Injection and cross-site scripting

SQL injection (SQLi) is confirmed by showing that input changes the query, not by dumping data. Start with a

single quote in an input field and watch for a database error or a change in behavior. Follow with a boolean test:

two inputs that should return different results if the input reaches the query, such as a true condition and a false

condition appended to the same parameter. If the application's responses differ exactly as the conditions

predict, the input is reaching the query, and the injection is confirmed. Never use destructive statements, never

extract more than the proof requires, and never run injection tests against production data.

Cross-site scripting (XSS) is confirmed by showing that input is reflected or stored without encoding, using a

harmless, unique marker string rather than an active payload. Submit a distinctive string in an input, then

search the response for that string unencoded. If it appears unencoded in the page, the reflection is proven, and

the finding is real regardless of whether a browser would execute it. Reflected XSS proves the flaw in one

request and response. Stored XSS proves it when the marker reappears for other users or later visits.

DOM-based XSS proves it when client-side code writes the marker into the page without encoding. In each case

the marker, not an exploit, is the proof.

7.2 Access flaws: IDOR, traversal, and authentication bypass

Insecure direct object reference (IDOR) is confirmed by changing an object identifier and observing whether

access control follows. Request your own record, then request the same resource with a neighboring identifier,

and observe whether the application serves another user's data or rejects the request. If it serves the data,

authorization is missing on that object, and the finding is proven with two requests and no special tooling. The

exam angle is the distinction between authentication and authorization: the tester is logged in, the tester is who

they claim to be, and the application still serves data the tester should not see. Authentication passed;

authorization failed.

Path traversal is confirmed by asking for a file outside the intended directory and reading the response. A

sequence of parent-directory references in a file parameter, or an encoded variant of the same sequence, that

returns a system file proves the application builds file paths from untrusted input without validation. Test with a

harmless, well-known file on your own lab system, and read the response for the file's contents rather than an

error. Directory traversal and its cousins, including log poisoning and null-byte tricks on older systems, all share

the same root cause: untrusted input reaching a file path.

Authentication bypass is confirmed by showing that a control meant to restrict access can be sidestepped.

Common proofs include requesting a restricted page directly without going through the login flow (forced

browsing), modifying a client-side parameter that claims a role or privilege, replaying or tampering with a

session token, and reusing a session after logout. Each proof has the same shape: the application trusts

something the client controls. The tester documents the exact request that bypassed the control, because the fix

is server-side enforcement, and the developer needs to see precisely which check was missing.

7.3 SSRF, upload flaws, and TLS checks

Server-side request forgery (SSRF) is confirmed by making the server fetch a resource you control and observing

the result. In a lab, point a suspect parameter at an address you own, such as a listener on your own lab

machine, and watch for the incoming connection: if the server connects, it is issuing requests on your behalf.

The dangerous form, fetching internal services or cloud metadata endpoints, is proven the same way in

principle, but the tester proves it in the lab against lab services, never by reaching for real internal systems

outside the authorization. The exam angle is the trust inversion: the server, which sits inside the trust boundary,

becomes the attacker's proxy.

File upload flaws are confirmed by testing what the application accepts and what it does with the file. Change

the extension, the content type, and the filename casing, and observe whether a file the application should

reject is stored and reachable. Double extensions and case variations defeat allowlists that check only one form.

The proof is a stored file that the application serves back, on your own lab system, with harmless content. The

dangerous outcome, a stored file that executes on the server, is demonstrated by the application's willingness

to store and serve it, not by executing a real payload against a real target.

TLS checks are configuration validation, not exploitation. Confirm the certificate is valid, unexpired, and issued

for the hostname being visited. Confirm the server still offers weak protocols or ciphers, such as TLS 1.0 or 1.1,

or cipher suites without forward secrecy. Confirm whether HTTP strict transport security is present, which tells

browsers to refuse plaintext connections. A TLS finding is usually a hardening finding rather than a critical one,

but it matters in combination: a login page served with a weak configuration, or a certificate mismatch a user

has been trained to click past, turns a hardening note into an attack path.

8. Prioritizing findings for exploitation

Discovery produces a list. Exploitation needs an order. The exploitation phase has limited time, and the order

decides whether it produces a meaningful result or a pile of low-value shells. Prioritization is where the tester's

judgment becomes visible, and the exam tests it as a ranking exercise: given several findings with context, which

goes first and why?

8.1 Exposure, public exploits, and attack chains

Exposure comes first. An internet-facing flaw is reachable by anyone, while an internal flaw requires a foothold

first. A flaw on a system holding customer data outranks the same flaw on an isolated test host. Public exploit

availability comes second: a flaw with a working public exploit or a Metasploit module is a flaw the tester can use

quickly and reliably, while a flaw needing custom exploit development may consume the whole test window.

Threat activity comes third: a flaw actively exploited in the wild, signaled by a high EPSS score or current

reporting, outranks a flaw nobody is using, because the window for the client is already closing.

Attack chains change the arithmetic. Two low-severity findings that combine into a critical path outrank either

finding alone. An information disclosure that reveals a username, plus a weak password policy, plus a missing

lockout, chains into account takeover. A reflected XSS that steals a session token, plus missing authorization on

an administrative function, chains into full compromise. The tester ranks chains, not just findings, and the report

describes the chain as one result with one severity, because that is how the client must fix it: break any link and

the chain fails.

8.2 Compensating controls and the final order

Compensating controls lower priority without removing the flaw. A web application firewall rule blocking an

injection pattern reduces the immediate risk but does not fix the code. Network segmentation containing a

vulnerable host reduces its blast radius but does not patch it. Endpoint detection watching for an exploit

technique raises the chance of catching it but does not prevent it. The tester records the control, credits it

honestly, and still reports the flaw, because controls fail, get misconfigured, and get removed, while the flaw

remains until fixed.

The final order for exploitation follows from all of this, and it is worth stating as a procedure the tester can apply

to any list:

1. Rank by exposure first: internet-facing and data-bearing systems before internal and isolated ones.

2. Rank by exploitability second: public exploits and weaponized code before flaws needing custom

development.

3. Rank by chaining third: findings that combine into a path to a valuable goal before isolated findings of

similar severity.

4. Adjust for compensating controls: credit controls that genuinely reduce risk, but never let a control erase

a finding.

5. Confirm the top findings before exploiting them: a validated critical beats an unvalidated critical, because

the exploitation phase must not spend its window on ghosts.

Chapter check

1. A non-credentialed scan reports a critical vulnerability on a server, but a credentialed rescan shows the

finding is gone and the patched package is installed. What most likely caused the original report?

A. The scanner's plugin feed was expired

B. Banner-based detection of a backported patch

C. A zero-day vulnerability in the scanner itself

D. The host was offline during the first scan

2. A tester wants to validate a new detection rule for one specific ATT&CK technique, credential dumping, in

isolation. Which approach fits best?

A. A full adversary campaign emulation

B. A network vulnerability scan of the estate

C. A cloud configuration benchmark

D. A single-technique test mapped to that ATT&CK technique

3. An OpenVAS report lists a finding with a QoD of 70 percent based on a version banner. What does the QoD

value tell the analyst?

A. The finding carries moderate confidence from banner-based detection

B. The finding is confirmed by a credentialed check

C. The finding is a confirmed false positive

D. The finding requires no further validation

4. During DAST testing of a web application, the report comes back clean. The application has an authenticated

administrative section and several multi-step workflows. What should the tester question first?

A. Whether the scanner's plugin feed is current

B. Whether the application has any vulnerabilities at all

C. Whether the crawler reached the authenticated pages and workflows

D. Whether the test window was long enough

5. A CVSS base score is 9.8 for a flaw on an isolated server with no network path from untrusted networks and

no public exploit. A second flaw scores 6.5 on an internet-facing server with a public exploit module and active

exploitation in the wild. Under risk-based prioritization, which should be addressed first?

A. The 9.8 flaw, because CVSS score always decides priority

B. The 6.5 flaw, because exposure and active exploitation raise its risk above the isolated flaw

C. Both equally, because they are in different severity bands

D. Neither until environmental scores are formally calculated

6. A tester submits a unique marker string into a search field and finds that string returned unencoded in the

response page. What has been proven?

A. A SQL injection flaw

B. An insecure direct object reference

C. A server-side request forgery flaw

D. A reflected cross-site scripting flaw

7. A cloud assessment tool produces an HTML report listing a public storage bucket and an overly permissive

security group. Which category of tool produced this output?

A. A cloud infrastructure assessment tool

B. A network vulnerability scanner

C. A web application scanner

D. A packet analysis tool

8. A scanner requests a known dangerous file from a web server and receives the site's custom error page with a

200 OK status. The scanner reports the file as present. What is the most likely explanation?

A. The file is genuinely present on the server

B. A credentialed scan confirming the file's contents

C. An error-page signature match producing a false positive

D. A banner-based detection of the server version

Answer key: 1. B - 2. D - 3. A - 4. C - 5. B - 6. D - 7. A - 8. C

Discovery Toolkit: Scanners for Artifacts, Clusters, and Secrets

Chapter 3 covered scan types, scanner output, and scoring. The objectives also name the newer scanning generation — tools that scan things (images, bills of materials, repositories, clusters) rather than only live hosts. These six are tested by name, and the distinctions between them are pure exam material.