CTI for Vulnerability Prioritization & Outbound Connection Investigation

The Vulnerability Prioritization Problem

A medium-sized organization runs a vulnerability scan and receives 4,000 findings. CVSS scores range from 3.0 to 10.0. Every critical finding is labeled urgent. The security team has capacity to remediate 50 vulnerabilities this sprint. Which 50?

CVSS score alone does not answer this. A CVSS 10.0 vulnerability in software that is not internet-accessible and has never been exploited in the wild is less urgent than a CVSS 7.0 vulnerability with active exploitation campaigns targeting your industry sector. Threat intelligence is what adds the context to make that distinction.

CVSS vs EPSS vs Active Exploitation

CVSS measures the theoretical severity of a vulnerability if exploited. EPSS (Exploit Prediction Scoring System) estimates the probability of exploitation in the wild within 30 days. Active exploitation — confirmed by threat intel sources — means exploitation is already happening now. For prioritization: active exploitation always wins, regardless of CVSS score.

Intelligence Sources That Inform Vulnerability Priority

Source	What It Provides	How to Use in Prioritization
CISA KEV (Known Exploited Vulnerabilities)	CVEs confirmed exploited in the wild — CISA-mandated remediation for federal agencies but useful for all	Any CVE on the KEV catalog is confirmed exploited — immediate prioritization regardless of CVSS
EPSS Score	Machine-learning probability of exploitation in next 30 days (0.0–1.0)	EPSS > 0.5 combined with asset exposure = high priority. EPSS < 0.05 on a non-exposed asset = defer
Sector ISAC Reports	Campaigns targeting your specific industry vertical — healthcare, finance, energy	CVEs being actively used in campaigns against your sector rise to top priority regardless of other factors
Vendor Security Bulletins	Vendor-confirmed exploitation status, available patches, mitigating controls	Vendor confirmation of exploitation = treat as active. Vendor 'no known exploitation' = rely on EPSS
CTI Platform IOC Correlation	CVEs associated with specific threat actor TTPs — attacker tools and exploits linked to vulnerability IDs	If your threat model includes a specific threat actor and they use an exploit kit targeting CVE-X — CVE-X is your top priority

The Prioritization Workflow — From 4,000 to 50

Step 1: Apply Exploitation Context

splunk-spl

# Vulnerability prioritization query — join vulnerability scan results with CTI context

# Start with scan data (from Qualys, Tenable, or similar exported to SIEM):
index=vuln_scan
| eval cve_list = split(CVEReferences, ",")
| mvexpand cve_list
| eval cve = trim(cve_list)

# Join with CISA KEV list (imported as lookup table):
| lookup kev_catalog cve_id AS cve OUTPUT due_date, ransomware_use
| eval kev_status = if(isnotnull(due_date), "CONFIRMED EXPLOITED", "not in KEV")

# Join with EPSS scores:
| lookup epss_scores cve AS cve OUTPUT epss_score
| eval epss_tier = case(
    epss_score >= 0.5, "HIGH_PROBABILITY",
    epss_score >= 0.1, "MODERATE",
    true(), "LOW"
  )

# Calculate priority score:
| eval priority_score = case(
    kev_status="CONFIRMED EXPLOITED", 100,
    epss_tier="HIGH_PROBABILITY" AND severity="Critical", 80,
    epss_tier="HIGH_PROBABILITY" AND severity="High", 60,
    epss_tier="MODERATE" AND severity="Critical", 40,
    true(), 10
  )

| sort -priority_score
| table cve, Asset, severity, epss_score, kev_status, priority_score
| head 50

Step 2: Add Asset Exposure Context

A vulnerability on an internet-exposed system is categorically more urgent than the same vulnerability on an isolated internal system. Asset exposure is the multiplier that CTI cannot provide on its own — it requires asset inventory knowledge.

Asset Exposure Tier	Priority Multiplier	Examples
Internet-facing, publicly accessible	3x base priority	Web servers, VPN concentrators, email gateways, DNS servers
Internal but reachable from untrusted segments	2x base priority	Database servers accessible from DMZ, jump hosts, admin interfaces
Internal, authenticated access only	1x base priority	Internal application servers, file servers, workstations
Air-gapped or highly restricted	0.5x base priority	Industrial control systems, research networks with strict access control

Step 3: Layer in Threat Actor Context

splunk-spl

# Check if any of your high-priority CVEs are in known threat actor tool kits
# This data comes from CTI platform exports or manual threat actor profiles

# If you maintain threat actor profiles in your SIEM:
index=threat_actor_profiles
| where actor_name IN ("Lazarus Group", "APT29", "FIN7")
| mvexpand cve_list
| table actor_name, cve_list, campaign, last_seen

# Cross-reference with your vuln scan results:
| join cve [search index=vuln_scan | table cve, Asset]
| stats count as affected_assets, values(Asset) as asset_list by cve, actor_name
| sort -affected_assets
| table cve, actor_name, affected_assets, asset_list

# Result: CVEs that known threat actors use, on your assets = immediate remediation
# regardless of CVSS score or EPSS value

Investigating Suspicious Outbound Connections With CTI

A firewall alert fires: an internal host made a connection to an external IP. Is this malware C2, a legitimate cloud service, an employee's personal device, or a misconfigured application? CTI is what answers that question in seconds instead of hours.

The Enrichment Workflow

splunk-spl

# Starting point: firewall log shows connection to unknown external IP
# IP: 185.220.101.45 from internal host 10.1.1.85

# Step 1: Enrich the destination IP against threat intel
| makeresults
| eval ip="185.220.101.45"
| lookup threat_intel_ioc ioc AS ip OUTPUT category, threat_type, confidence, last_seen, campaigns
| table ip, category, threat_type, confidence, last_seen, campaigns

# Step 2: Check passive DNS — what domains resolve to this IP?
# Query your threat intel platform API or a CTI lookup table:
| lookup passive_dns ip OUTPUT hostname, first_seen, last_seen
| table ip, hostname, first_seen, last_seen

# Step 3: Check IP reputation and WHOIS context
| lookup ip_reputation ip OUTPUT asn, asn_name, country, registration_date, abuse_score
| eval suspicious_indicators = case(
    registration_date > relative_time(now(), "-30d"), "recently registered",
    asn_name LIKE "%hosting%", "hosting provider ASN",
    country IN ("XX", "YY"), "high-risk jurisdiction",
    true(), "clean"
  )

# Step 4: Check if this destination was seen in any other alerts or hunts
index=* (dst_ip="185.220.101.45" OR dst_hostname="*domain*")
| stats count by src_ip, index, sourcetype
| sort -count

Interpreting the Enrichment Results

CTI Finding	Investigation Direction	Urgency
IP confirmed in threat intelligence as known C2 infrastructure	Endpoint investigation on source host — check for malware, lateral movement, persistence	Critical — treat as active compromise until ruled out
IP on Tor exit node list	Outbound policy decision — was Tor allowed intentionally? Check for beaconing pattern	High — warrants escalation if beaconing pattern confirmed
IP associated with known threat actor campaign in same sector	Full investigation — this is not noise. Scope the compromise before containment	High — sector-specific targeting is intentional
IP is a commercial hosting provider with no threat intel hits	Check what application is making the connection — may be legitimate SaaS or shadow IT	Low — investigate identity of the application, not the threat
IP resolves to a recently registered domain with privacy registration	Investigate further — new domains with privacy registration are a common attacker pattern	Medium — combine with endpoint investigation to determine

Building an Internal CTI Enrichment Pipeline

Manual enrichment of every alert is not scalable. A CTI pipeline automates the enrichment so that every alert already has context when the analyst opens it.

Ingest threat intelligence feeds into the SIEM as lookup tables — updated daily: IP reputation, known-bad domains, file hash blocklists, CVE exploit status
Configure SOAR playbooks to enrich IP/domain/hash indicators automatically when an alert fires — analyst sees enriched alert, not raw data
Maintain internal enrichment: asset classification, owner, criticality — this is the context no external feed has
Build a false-positive reduction layer: if IP belongs to known-good CDN or SaaS provider, auto-close the enrichment step
Track enrichment quality: what percentage of escalated alerts had threat intel that predicted the outcome? High correlation = good feed selection. Low correlation = feed quality issue

→

The ROI of CTI is measured in analyst decision time. An enrichment pipeline that reduces the time from alert to prioritization decision from 20 minutes to 2 minutes is worth more than any single threat feed. Invest in automation before investing in additional feed subscriptions.

Previous Module Next Module