Module 4: Vulnerability Correlation
Overview
In Module 2, you mapped your target's external attack surface -- domains, subdomains, and exposed services. In Module 3, you identified the people whose credentials could unlock those services. This module connects the assets you discovered to known vulnerabilities, with emphasis on vulnerabilities that are actively being exploited in the wild.
Your Attack Surface Is Your Vulnerability Scope
The vulnerability correlation process starts with what you already found. Every identifiable product and version from Module 2 -- VPN portals, web servers, remote access gateways, administrative interfaces -- is a candidate for vulnerability lookup. You are not scanning the internet for every possible CVE; you are answering a specific question: do the systems I found exposed have known vulnerabilities that attackers are actively exploiting?
The Asset-to-Vulnerability Workflow
The workflow follows a consistent pattern for each exposed asset:
- Identify product and version -- From Shodan/Censys banners, HTTP headers, login page styling, SSL certificate details, AI-assisted analysis of raw service data, and your organization's internal asset inventory. External discovery reveals what an attacker can see; internal records often provide exact version numbers, patch levels, and network context that external fingerprinting cannot
- Generate CPE identifier -- The Common Platform Enumeration (CPE) is the standard naming scheme for IT products. A CPE like
cpe:2.3:o:fortinet:fortios:7.4.6:*:*:*:*:*:*:*uniquely identifies a specific product version in vulnerability databases - Query vulnerability databases -- Use the CPE to search NVD, check CISA KEV, review vendor PSIRTs, and check ICS-specific advisories
- Prioritize by active exploitation -- A vulnerability on the CISA KEV list is confirmed to be exploited in the wild. Combined with internet exposure from Module 2, this is the highest-priority finding your monitoring program can produce
Vulnerability Intelligence Sources
No single source captures all relevant vulnerabilities. Use these in combination:
| Source | URL | What It Provides |
|---|---|---|
| NVD | nvd.nist.gov | Comprehensive CVE database with CVSS scores, CPE matching, and technical details |
| CISA KEV | cisa.gov/known-exploited-vulnerabilities-catalog | Vulnerabilities confirmed to be actively exploited -- the single highest-priority list for internet-exposed assets |
| CISA ICS Advisories | cisa.gov advisories | ICS/OT-specific advisories including SCADA, DCS, PLC, and industrial networking products |
| ICS Advisory Project | icsadvisoryproject.com | Aggregates ICS/OT vulnerability advisories from multiple sources into a centralized, searchable view. Note: Focuses on ICS/OT-specific vendors and products -- network infrastructure vendors like Fortinet, Palo Alto, and Cisco are generally not included. Use NVD and vendor PSIRTs for edge device and IT infrastructure products |
| Vendor PSIRTs | (varies by vendor) | Vendor-specific security advisories, often published before NVD entries. May include mitigations not in the CVE record |
Why KEV Matters Most
The CISA Known Exploited Vulnerabilities catalog is not a theoretical risk list. Every entry represents a vulnerability that CISA has confirmed is being used in real attacks. When you find a KEV-listed vulnerability on an internet-exposed asset from your Module 2 inventory, the risk equation is complete:
- Exposure (Module 2) -- the asset is reachable from the internet
- Vulnerability (this module) -- a known flaw exists in the product version
- Exploitation (confirmed by CISA KEV, CISA ICS advisory, or vendor PSIRT) -- attackers are actively using this flaw
This combination -- exposed + vulnerable + actively exploited -- is the highest-urgency finding your OSINT monitoring program can produce. It demands immediate action, not a quarterly review. CISA KEV is the most structured source for confirmed exploitation, but CISA ICS advisories and vendor PSIRT alerts can report active exploitation before a KEV entry exists -- all three sources can trigger a P0 classification.
Important caveat: CISA only adds a vulnerability to the KEV catalog when a patch or actionable mitigation is available from the vendor. This means KEV is an excellent action list -- every entry has a remedy -- but it is not a complete picture of active exploitation. Vulnerabilities being exploited before a patch exists (zero-days) will not appear on KEV until the vendor releases a fix. This is why monitoring vendor PSIRTs, CISA ICS advisories, and the ICS Advisory Project in parallel is essential -- they may report active exploitation before a KEV entry exists.
Edge Devices in ICS/OT Environments
For ICS/OT organizations, the most critical vulnerability correlation targets are often edge devices -- firewalls, VPN concentrators, and remote access gateways that sit at the boundary between the internet and internal networks. These devices are:
- Internet-facing by design -- they must be reachable to function
- High-value targets -- compromising the perimeter device provides access to everything behind it
- Frequently targeted -- Fortinet, Cisco, Palo Alto, and Ivanti edge devices have been repeatedly exploited by nation-state and criminal groups (Module 1 attack examples)
- Often bridges to OT -- the same VPN that provides IT remote access may terminate in or adjacent to OT networks
The Fortinet FortiGate example used in this module illustrates the pattern: a widely deployed edge device, a critical authentication bypass vulnerability, and exploitation within 3 days of disclosure.
Lab: Build Your Vulnerability Correlation Table
In this lab, you will take the assets discovered in Module 2, identify their products and versions, correlate them against vulnerability databases, and prioritize findings by active exploitation status. The output becomes Artifact 4.
This module requires more focused manual validation than the preceding modules. While automated vulnerability scanning and tracking tools have their place, the goal here is not to replicate a vulnerability scanner -- it is to understand the specific avenues that threat actors will gravitate toward based on your external exposure, and to improve your prevention and monitoring posture in those areas. Each finding should be verified against primary sources and understood in context, not just cataloged.
Step 1: Extract Product/Version Information and Generate CPE Identifiers
Review your Module 2 attack surface inventory. For each exposed service where you can identify a product and version, extract the relevant details:
- Product name and vendor -- from login page branding, HTTP headers, Shodan/Censys banners
- Version number -- from headers (
Server:,X-Powered-By:), page source, or banner data - Service type -- VPN portal, web server, administrative interface, API endpoint
Use your AI client to generate CPE identifiers and get an initial vulnerability assessment for each product:
I found the following product exposed to the internet during an
external attack surface assessment:
- Product: [vendor] [product name]
- Version: [version number]
- Service: [service type, e.g., HTTPS admin interface on port 443]
- Context: [where this sits in the network, e.g., perimeter
firewall for an electric utility]
1. Generate the CPE 2.3 identifier for this product and version
2. List all critical and high-severity CVEs from 2024-2026
affecting this version
3. For each CVE, indicate:
- CVSS score
- Whether it is on the CISA KEV (Known Exploited
Vulnerabilities) list
- Brief description of the vulnerability
- Whether remote/unauthenticated exploitation is possible
4. Highlight any CVEs that combine internet-facing exposure with
active exploitation -- these are the highest priority findingsVerify AI results. AI clients may generate plausible but incorrect CPE identifiers or hallucinate CVE details. Validate the CPE string using the NVD CPE Search -- this tool checks whether the CPE is syntactically valid and whether NVD recognizes the product/version combination. If the AI-generated CPE does not return results, try searching by vendor and product name to find the correct CPE format. For CVE details, always confirm CVSS scores against NVD and KEV status against the CISA KEV catalog. Programmatic CPE validation using scripts is possible but beyond the scope of this workshop.
Worked Example: FortiGate Vulnerability Correlation
Scenario
During Module 2 discovery, a FortiGate login portal was identified exposed to the internet. Shodan banner analysis revealed:
- Product: Fortinet FortiGate
- Version: FortiOS 7.4.6 (from HTTP headers and login page analysis)
- Service: HTTPS admin interface on port 443
- Context: Primary perimeter firewall / SSL-VPN remote access gateway
CPE Identifier
cpe:2.3:o:fortinet:fortios:7.4.6:*:*:*:*:*:*:*
Shodan Search Query
Students with Shodan accounts can search for exposed FortiGate instances:
product:"FortiGate" port:443 "FortiOS"
Look for: version numbers in HTTP headers or login page HTML, SSL certificate details revealing organization name, administrative login portals exposed to the internet. Shodan data shows approximately 189,000 internet-exposed FortiOS 7.x admin interfaces, with roughly 30,000 having FortiCloud SSO enabled.
Step 2: Vulnerability Database Queries
For each product identified in Step 1, query multiple vulnerability sources. No single database is complete -- cross-referencing catches what any one source might miss.
| Source | How to Search | What to Record |
|---|---|---|
| NVD | Search by CPE or keyword at nvd.nist.gov/vuln/search | CVE ID, CVSS score, description, affected versions, published date |
| CISA KEV | Search by vendor or CVE at CISA KEV catalog | KEV listing date, required remediation date, exploitation confirmation |
| CISA ICS Advisories | Filter by vendor at CISA advisories | ICS-specific context, affected sectors, mitigations |
| ICS Advisory Project | Browse or search at icsadvisoryproject.com | Aggregated view of ICS/OT advisories, affected products, vendor response status |
| Vendor PSIRT | Search vendor's security advisory page (see below) | Vendor-specific severity, workarounds, patch availability, affected product lines |
ICS Advisory Project coverage note. The ICS Advisory Project is valuable for SCADA, DCS, PLC, and industrial networking products but does not track IT infrastructure vendors (Fortinet, Palo Alto, Cisco, etc.). For edge devices and network infrastructure, use NVD and vendor PSIRTs directly.
Common ICS/OT Vendor PSIRTs
| Vendor | PSIRT / Advisory Page |
|---|---|
| Fortinet | fortiguard.fortinet.com/psirt |
| Siemens | Siemens ProductCERT |
| Schneider Electric | Schneider Electric Security Notifications |
| Rockwell Automation | Rockwell Security Advisories |
| ABB | ABB Cybersecurity Alerts |
Worked Example: FortiGate Vulnerability Database Results
NVD Search: "fortinet fortios 7.4"
NVD returns multiple CVEs affecting FortiOS 7.4.x. The critical findings for our FortiOS 7.4.6 instance:
| CVE | CVSS | KEV | Description |
|---|---|---|---|
| CVE-2025-59718 | 9.8 | Yes (Dec 16, 2025) | SSO authentication bypass via crafted SAML assertion -- allows unauthenticated administrative access |
| CVE-2025-59719 | 9.8 | Yes | Same root cause as CVE-2025-59718, affects FortiWeb. Relevant if FortiWeb is also deployed |
| CVE-2026-24858 | -- | Monitoring | Follow-on SSO bypass affecting devices that patched CVE-2025-59718. Demonstrates ongoing exploitation campaign |
CISA KEV Check: "fortinet"
CVE-2025-59718 was added to the KEV catalog on December 16, 2025 -- just 7 days after disclosure (December 9, 2025) and 4 days after confirmed exploitation in the wild (December 12, 2025). This timeline illustrates why continuous monitoring matters: the window between disclosure and active exploitation was 3 days.
Fortinet PSIRT: FG-IR-25-647
The Fortinet advisory at fortiguard.fortinet.com/psirt/FG-IR-25-647 provides:
- Affected versions: FortiOS 7.6.0-7.6.3, 7.4.0-7.4.8, 7.2.0-7.2.11, 7.0.0-7.0.17
- Key detail: FortiCloud SSO is automatically enabled when a device is registered via the GUI -- many administrators do not realize this feature is active, making them vulnerable without knowing it
- Observed attack pattern: Authenticate as admin via SSO bypass --> download system configuration (including hashed credentials) --> crack hashes offline --> establish rogue VPN tunnels for persistent access
CISA Alerts
- CISA Alert: CVE-2025-59718 added to KEV (December 16, 2025)
- CISA Alert: CVE-2026-24858 follow-on exploitation (January 28, 2026)
The CVE-2026-24858 follow-on is particularly significant: even organizations that patched the original CVEs faced a new bypass. This demonstrates that edge device vulnerability monitoring is ongoing, not a one-time exercise.
Step 3: Active Exploit Prioritization and Risk Summary
Not all CVEs carry equal urgency. Use the following prioritization framework to rank your findings:
| Priority | Criteria | Action |
|---|---|---|
| P0 -- Active Exploitation | Internet-exposed asset + confirmed active exploitation (CISA KEV, CISA ICS advisory, or vendor PSIRT alert) + remote or unauthenticated exploitation possible | Immediate notification to asset owner. Patch or mitigate within hours, not days |
| P1 -- Critical | Internet-exposed asset + CVSS 9.0+ + no KEV listing yet, or KEV-listed but requires authentication | Urgent remediation within 48 hours. Monitor for exploitation reports |
| P2 -- High | Internet-exposed asset + CVSS 7.0-8.9, or internal-only asset with KEV listing | Remediation within standard patch cycle. Add to monitoring list |
| P3 -- Monitor | Known vulnerability but no internet exposure, or low CVSS with no exploitation evidence | Track in vulnerability inventory. Address in next maintenance window |
For your highest-priority findings (P0 and P1), generate a risk summary that your security team or management can act on immediately:
Write a one-paragraph risk summary for my security team about
this finding:
- Asset: [vendor] [product], [version]
- Exposure: [service type] on port [port], internet-facing
- Vulnerability: [CVE ID] (CVSS [score], CISA KEV since [date])
- Attack pattern: [brief description of how the vulnerability
is exploited]
- Context: [what this asset does in the organization -- e.g.,
primary perimeter firewall, remote access gateway for OT
network]
Include:
1. Why this is urgent (active exploitation + exposure + asset
criticality)
2. Recommended immediate actions (patch, mitigate, monitor)
3. What to check for evidence of prior compromiseWorked Example: FortiGate Risk Summary
Prompt filled in for the FortiGate finding:
Write a one-paragraph risk summary for my security team about this finding:
Asset: Fortinet FortiGate firewall, FortiOS 7.4.6
Exposure: Admin interface on port 443, internet-facing
Vulnerability: CVE-2025-59718 (CVSS 9.8, on CISA KEV since Dec 16, 2025)
Attack pattern: Unauthenticated SSO bypass via crafted SAML assertion --> admin access --> config export with hashed credentials --> rogue VPN tunnel creation
Context: This is the primary perimeter firewall for an electric cooperative
Example AI Response (FortiGate Risk Summary)
Risk Summary: FortiGate CVE-2025-59718 -- P0 Active Exploitation
CRITICAL -- IMMEDIATE ACTION REQUIRED: Our internet-facing Fortinet FortiGate firewall (FortiOS 7.4.6) is vulnerable to CVE-2025-59718, a CVSS 9.8 authentication bypass that has been on the CISA Known Exploited Vulnerabilities list since December 16, 2025. This vulnerability allows an unauthenticated attacker to bypass FortiCloud SSO using a crafted SAML assertion, gaining full administrative access to the device without any credentials. The observed attack pattern is: gain admin access --> export the device configuration (which contains hashed credentials for all VPN users) --> crack password hashes offline --> create rogue VPN tunnels for persistent access to the internal network. Because this device serves as our primary perimeter firewall and SSL-VPN gateway -- the same device that provides remote access to staff and vendors, potentially including paths to our OT network -- a successful compromise would give an attacker a persistent, authenticated tunnel into our infrastructure.
Recommended immediate actions:
- Patch immediately to FortiOS 7.4.9 or later (the minimum version that addresses both CVE-2025-59718 and the follow-on CVE-2026-24858)
- Check for compromise: Review admin login logs for unfamiliar sessions or logins from unexpected source IPs. Check for newly created VPN tunnels or user accounts that were not provisioned by your team. Export and review the current device configuration for unauthorized changes
- If compromise is suspected: Rotate all VPN user credentials immediately (the configuration export contains hashed passwords). Revoke and reissue SSL certificates. Audit all firewall rules for unauthorized modifications
- Ongoing: Disable FortiCloud SSO if not required. Restrict management interface access to specific IP ranges. Monitor CISA advisories for follow-on CVEs in this exploitation campaign
This risk summary connects the Module 2 finding (internet-exposed FortiGate) to the vulnerability data (CVE-2025-59718, KEV-listed), ties it to the attack pattern from Module 1 (Fortinet campaign), and provides actionable remediation steps. The Module 3 personnel findings become relevant here too -- if a compromised configuration exports hashed credentials, the personnel in your Tier 1 list who use VPN access are at immediate risk.
Step 4: Document Your Vulnerability Correlation Table
Consolidate all findings into a structured asset-vulnerability correlation table. This table becomes Artifact 4 and feeds directly into your Module 6 runbook (which vulnerabilities to monitor) and Module 5 monitoring setup (which alert sources to subscribe to).
For each finding, document:
| Field | Description |
|---|---|
| Asset | Hostname, IP, and service from Module 2 inventory |
| Product / Version | Vendor, product name, and version number |
| CPE | CPE 2.3 identifier for database queries |
| CVE(s) | All relevant CVE identifiers with CVSS scores |
| KEV Status | Yes/No -- is this CVE on the CISA KEV list? Include date added |
| Priority | P0 / P1 / P2 / P3 based on the prioritization framework |
| Vendor Advisory | Link to vendor PSIRT advisory for patch information |
| Notes | Attack pattern, mitigations, or cross-references to Module 2/3 findings |
Not every asset will have findings. If an exposed service has no identifiable product/version, or no matching CVEs, document it as "no version identified" or "no critical CVEs found" rather than omitting it. The absence of findings is still useful information -- it means either the product is well-patched, the version could not be fingerprinted (which may itself warrant investigation), or the product is not well-covered by public vulnerability databases.
Connecting Modules 2, 3, and 4
Your vulnerability correlation table does not exist in isolation. Cross-reference your findings:
- Module 2 (Attack Surface) -- Which exposed services have the most critical vulnerabilities? These assets may need network-level mitigations (IP restriction, WAF, or takedown) in addition to patching
- Module 3 (Personnel) -- Which personnel have VPN or remote access credentials to the vulnerable systems? A breached credential for someone with access to a P0-vulnerable system escalates both findings
- Module 5 (Monitoring) -- Which vendor PSIRTs and CISA feeds should you subscribe to for ongoing vulnerability alerts on these products?
- Module 6 (Runbook) -- How frequently should you re-check these products against vulnerability databases? P0 findings need immediate response procedures; routine correlation can be weekly or monthly
The vulnerability correlation table is a focused, manually validated assessment of your highest-risk exposure -- not an exhaustive CVE list. Maintaining it requires periodic re-validation as products are patched, new CVEs are disclosed, and your attack surface changes. Modules 5 and 6 establish the monitoring cadence and procedures to keep this table current.
Output
Artifact 4: Vulnerability correlation table with active-exploit prioritization. A structured table mapping each exposed asset (from Module 2) to its known vulnerabilities, with CPE identifiers, CVE details, CISA KEV status, and priority ratings. This table identifies which assets require immediate remediation, which vendor advisory feeds to monitor (Module 5), and which vulnerability checks to include in your recurring runbook procedures (Module 6).
Record your findings in the Vulnerability Correlation Table Template (download Excel).