Passive Vulnerability Assessment

What it is

Passive vulnerability assessment is the practice of identifying potential security exposures without sending exploit traffic at the target. Rather than testing whether a vulnerability is exploitable by attempting to exploit it, passive assessment observes what services say about themselves and cross-references that information against vulnerability databases.

The data sources are exactly the kind of thing that any internet user can collect without authorisation:

• Service banners. SSH, FTP, SMTP, HTTP and many other protocols announce their software and version on connection. A response of OpenSSH_7.4 is a piece of vulnerability intelligence.
• TLS certificate details. Subject, issuer, validity dates, key strength, signature algorithm.
• HTTP response headers. Server, X-Powered-By, framework-specific fingerprints.
• HTML and JavaScript content. Meta tags, comments, library version strings, asset paths that reveal the CMS or framework in use.
• DNS records. MX, SPF, DMARC, CAA, and other records that indicate configuration weaknesses.
• Public certificate transparency logs. Records of every certificate ever issued for your domains.
• Internet-wide scan data. Aggregators like Shodan and Censys cache responses from every IP on the internet, accessible by API.

From those signals, passive tools infer the running technology stack, map known vulnerabilities to it, and generate a list of probable exposures. No exploit is attempted. No state changes on the target system. The traffic generated is indistinguishable from a normal user connection.

Why it matters

The reason passive assessment is so valuable is that it can be run continuously and broadly. Active scanners produce noise, can crash fragile systems, and require coordination with operations teams. Passive tools do not, so you can point them at every IP you own every day.

The business value plays out in a few ways:

• Coverage. A passive scan covers the full external attack surface continuously. An active scan typically covers a small subset on a periodic schedule.
• Speed. Newly exposed services are visible within hours. The window between exposure and detection shrinks dramatically.
• Operational safety. Production teams can sign off on continuous passive scanning without worrying about service disruption. They are far more cautious about active testing, with good reason.
• Third-party visibility. You can passively assess vendors, partners, and acquisition targets without their cooperation. This is especially valuable in M&A and supply chain risk.
• Attacker symmetry. Attackers run passive reconnaissance against you continuously. Defenders running the same kind of analysis against themselves see what attackers see.

The blind spots are real and worth being honest about. Passive assessment cannot tell you whether a vulnerability is actually exploitable in your environment, only that the version in use has known issues. It cannot test custom application logic. It cannot find SQL injection or XSS in your bespoke code. For those, you need active testing or code review.

How attackers exploit it

Attackers love passive reconnaissance because it generates almost no signal that a defender can detect.

The reconnaissance flow looks like:

1. Identify the target. A specific organisation, a sector, or anyone running a specific vulnerable service.
2. Pull data from Shodan, Censys, FOFA, ZoomEye and similar services. A query like "Apache 2.4.49 in country X" returns thousands of candidate hosts. The 2021 path traversal CVE in that version (CVE-2021-41773) had mass exploitation within days because finding vulnerable hosts was trivial.
3. Cross-reference banners with the CVE database. Each version string maps to known issues.
4. Filter by exploitability. Public exploit code, CISA KEV inclusion, ransomware crew interest. Prioritise the targets with the highest payoff and easiest exploitation.
5. Move to active exploitation only against pre-vetted targets. By the time the attacker actually touches the system, they already know what to do.

For high-profile vulnerabilities, this entire flow takes minutes. CVE-2024-3400 (PAN-OS), CVE-2023-46805 and CVE-2024-21887 (Ivanti), and the ongoing Citrix NetScaler series all saw mass exploitation within hours of disclosure because passive recon let attackers identify every vulnerable host before defenders could patch.

The lesson for defenders is uncomfortable but useful: if you can find an exposure passively, so can an attacker, and they probably already have.

How to detect it

Detection in this context means using passive techniques on yourself to find exposures before attackers do. Practical methods:

• Banner-based scanning across all known IPs. TCP connect, read the banner, parse the version, look up known vulnerabilities. Repeat daily.
• HTTP fingerprinting. Pull headers, parse HTML, identify CMS, framework, library versions. Tools like Wappalyzer (and many others) catalogue thousands of fingerprintable technologies.
• TLS configuration analysis. Connect, read the certificate, enumerate cipher suites and supported protocol versions. Match against known weakness criteria.
• DNS configuration checks. Pull SPF, DMARC, DNSSEC, CAA records. Many organisations have weak or missing configurations that passive analysis surfaces immediately.
• Certificate transparency monitoring. Every certificate issued for your domains shows up in CT logs. Watch for unexpected new certificates and orphaned old ones.
• Cross-reference with KEV and EPSS. A version of OpenSSH from 2017 is one finding. The same version with a CISA KEV entry and an EPSS score above 90 is an incident.
• Differential scanning. Compare today's results against yesterday's. The interesting findings are usually the new ones.

The output of a good passive programme is not "1,247 vulnerabilities". It is "three things changed since yesterday and two of them are worth attention now". The triage is what makes the data useful.

How to remediate

Passive findings are a starting point, not a final verdict. Remediation flow:

1. Validate the finding. A banner can be wrong. Some teams deliberately spoof banners. Some products patch a vulnerability without bumping the version string. Confirm by checking the actual installed version where you can.
2. Assess exploitability in your environment. A vulnerable version of jQuery on a static marketing page is different from the same version on a banking application. Context matters.
3. Prioritise using exploitability data. CISA KEV inclusion, EPSS scores, public exploit availability, and active threat intelligence all narrow the list of "fix urgently" findings.
4. Apply the appropriate fix. Patch, upgrade, replace, or remove. For end-of-life software, replacement is the only real option.
5. Add compensating controls where patching is slow. WAF rules, network segmentation, or temporary access restrictions can buy time.
6. Re-scan to confirm. The passive scan that found the issue is also the easiest way to verify the fix.

For findings that turn out to be false positives, document the reason. The same finding will reappear next scan otherwise, generating noise that crowds out real issues.

Best practices

• Run passive assessment continuously, not periodically. Daily or better. Critical findings should generate alerts within hours.
• Combine passive with active testing. Use passive scanning for breadth, coverage and speed. Use active testing for depth, custom application logic, and exploitability validation.
• Feed results into prioritisation, not just reports. A passive finding without business context is noise. Tie each finding to an asset owner, business criticality, and remediation SLA.
• Track the rate of new findings, not just the count. A flat or growing total over time means remediation is not keeping up with discovery.
• Use the same techniques against vendors. Suppliers and partners with weak external posture are part of your risk surface. Passive assessment of their public-facing assets is a fair use of public information.
• Beware version banner spoofing. Some teams hide or fake banners as an obfuscation control. This is weak as a defence and creates noise for your own assessment. Patch the underlying issue rather than just the banner.
• Map findings to threat intelligence. A vulnerability that ransomware crews are actively exploiting is a different priority from one with no observed exploitation. Wire KEV, EPSS, and reputable threat feeds into your prioritisation.