Zero Day & CVE Response

What Zero Day Response Covers and When to Activate

A zero-day vulnerability is a software flaw that is either (a) publicly disclosed without a vendor patch, (b) actively exploited before the vendor knows about it, or (c) disclosed via CVE with a critical score and active exploit code in the wild.
MITRE ATT&CK maps vulnerability exploitation to T1588.006 (Obtain Capabilities: Vulnerabilities) — attackers weaponize CVEs to gain initial access, escalate privileges, or bypass defenses.
Activate this playbook when: (1) A CVE is published with CVSS 9.0+ and active exploit code, (2) CISA publishes a Known Exploited Vulnerability (KEV) alert relevant to your environment, (3) A vendor releases an emergency patch for an actively exploited vulnerability, or (4) Your organization’s threat intel team reports active exploitation of a zero-day affecting your tech stack.

Step 1: Triage the Disclosure (First 30 Minutes)

Information Gathering

When a new CVE or zero-day is announced, collect:

Field	What to Document	Source
CVE ID	Standard identifier	NVD, MITRE
CVSS Score	Severity rating (0-10)	NVD
Affected products	Software, version ranges	Vendor advisory
Exploitability	Attack vector, complexity, privileges needed, user interaction	CVSS vector string
Known exploits	Public PoC, Metasploit module, exploit kit inclusion	GitHub, Exploit-DB, CISA KEV
Active exploitation	Reports of in-the-wild exploitation	CISA, vendor blog, threat intel
Vendor patch status	Patch available, workaround only, or no fix yet	Vendor security advisory

Triage Decision Matrix

CVE Profile	Priority	Response Timeline
CVSS 9.0+ + Active exploitation + Public PoC	Critical	Begin immediately. Emergency patching
CVSS 7.0-8.9 + Active exploitation	High	Begin same day. Schedule patching within 24h
CVSS 9.0+ + No known exploitation + No PoC	High	Begin same day. Test and schedule patching within 72h
CVSS 7.0-8.9 + No exploitation + PoC available	Medium	Schedule patching within 7 days
CVSS < 7.0 + No exploitation	Low	Include in next patch cycle

Step 2: Asset Discovery and Exposure Assessment (1-2 Hours)

Find Affected Assets

# Search configuration management database (CMDB) for affected software
# Query your asset inventory — crowdstrike, tenable, or CMDB API

# Search SIEM for affected software versions
index=windows sourcetype=WinEventLog:Application
| search ProductName="*VulnerableProduct*" ProductVersion="*affected_ver*"
| stats dc(Computer) as Affected_Systems by ProductName, ProductVersion

Exposure Assessment

Assessment	Question	Method
Asset count	How many systems run the vulnerable software?	CMDB query, EDR inventory, vulnerability scanner
Network exposure	Is the vulnerable service accessible from the internet?	Perimeter firewall rules, external port scan
Business criticality	Are the affected systems production, development, or test?	CMDB tags, business impact assessment
Data sensitivity	What data do the affected systems process?	Data classification tags, data flow diagrams
Exploit path analysis	Can an attacker chain this CVE with other vulnerabilities?	Attack path mapping, reachability analysis

Prioritize Systems for Patching

Priority	System Type	Patching Window
P0	Internet-facing, critical data, no compensating controls	Emergency — within hours
P1	Internet-facing OR critical data	Same day
P2	Internal-facing, production systems	24-72 hours
P3	Internal non-production, dev/test	7 days
P4	Air-gapped, isolated, or compensated	Next scheduled maintenance

Step 3: Compensating Controls — Patching Delay Mitigation

When a patch is not immediately available (vendor hasn’t released one, or patching requires a maintenance window), deploy compensating controls:

Network-Level Controls

Control	Works Against	Implementation
WAF rule	Web-based exploits (SQLi, RCE, SSRF)	Add virtual patch rule — block known exploit patterns
IPS/IDS signature	Network-based exploitation	Snort and Suricata rule blocking exploit traffic
Firewall ACL	Exploits reaching vulnerable services	Block source IPs, restrict access to affected ports
Rate limiting	Brute-force or DoS exploitation	Limit connections per source IP to vulnerable service
DNS RPZ	C2-based post-exploitation	Sinkhole known C2 domains

Endpoint-Level Controls

Control	Works Against	Implementation
EDR behavioral rule	Exploitation behavior (process injection, file creation)	Write custom detection rule
ASLR/CFG	Memory corruption exploits	Enable system-wide exploit mitigations
AppLocker	Unauthorized binary execution	Enforce allowlisting on critical systems
Disable vulnerable component	Component-specific exploits	Stop and disable vulnerable service where possible
Registry mitigation	Registry-level exploit mitigation	Apply vendor-provided registry fix or DisableRestrictedAdmin

Suricata Rule Template for Virtual Patching

# Virtual patch — block exploitation of CVE-YYYY-NNNNN
alert tcp any any -> $HOME_NET $HTTP_PORTS (
  msg:"CVE-YYYY-NNNNN — virtual patch for remote code execution";
  content:"/vulnerable/endpoint"; http_uri;
  content:"exploit_string"; http_client_body;
  classtype:attempted-admin;
  sid:1000001; rev:1;
  reference:cve,CVE-YYYY-NNNNN;
)

Step 4: Active Exploitation Monitoring

Once you have identified affected assets, monitor for exploitation attempts.

Monitor This Telemetry

Data Source	What to Monitor	Detection
Web server logs	Exploit patterns in URI, POST body, headers	Grep for exploit-specific strings
IDS/IPS alerts	Exploit signatures	Check for alerts matching CVE signature
EDR telemetry	Process creation, network connections	Monitor for unusual child processes from vulnerable service
Authentication logs	Post-exploitation lateral movement	Monitor for anomalous admin logins from the vulnerable host
Firewall logs	Outbound connections from vulnerable hosts	Beacon detection, data exfiltration patterns

SPL — Monitor for Post-Exploitation Activity

index=windows sourcetype=WinEventLog:Sysmon EventCode=1
| search ParentImage="*vulnerable_service*" OR ParentImage="*httpd*" OR ParentImage="*iis*"
| search Image="*cmd.exe*" OR Image="*powershell.exe*" OR Image="*wscript.exe*"
| stats count, values(CommandLine) as Commands by Computer, Image
| eval alert = "Post-exploitation activity from " . ParentImage . " spawning " . Image . " on " . Computer
| table _time, Computer, ParentImage, Image, CommandLine, alert

CVE-Specific Monitoring Checklist

CVE Type	What to Monitor	Example Detection
Remote Code Execution	Process tree from vulnerable service	IIS spawns cmd.exe — CVE-2021-31166
Privilege Escalation	CreateRemoteThread to SYSTEM process	Windows kernel exploit — CVE-2024-26234
SQL Injection	Unexpected query patterns in database logs	OR 1=1 patterns — CVE-2023-34362
XXE / SSRF	Outbound connections from app servers	Unexpected HTTP requests from web app to internal IPs
Memory corruption	Crash dumps, application restarts	Repeated crash of vulnerable service in short window

Step 5: Patch Deployment and Verification

Deployment Phases

Phase	Scope	Timing
Phase 1	Dev/test environment	Validate patch compatibility
Phase 2	Non-critical production	Deploy to low-risk systems first
Phase 3	Critical production	Scheduled maintenance window
Phase 4	Legacy / exception systems	Manual patching or compensating controls

Verification Checklist

# Verify patches are installed
# Windows
wmic qfe list brief /format:texttable
Get-HotFix | Where-Object {$_.HotFixID -eq "KBXXXXXXX"}

# Linux
dpkg -l | grep package_name
rpm -qa | grep package_name

# Verify service restart (if required)
Get-Service -Name vuln_service | Select-Object Status, StartType
systemctl status vulnerable.service

Exception Handling

Systems that cannot be patched must have documented exceptions:

Field	Example
System name	LEGACY-SRV-01
Reason for exception	Vendor EOL, no patch available, application incompatibility
Compensating control	WAF virtual patch + EDR behavioral rule + network segmentation
Approval	Signed by CISO and system owner
Review date	30 days — re-evaluate for patch

Communication Timeline

Time	Action	Audience
T+0	CVE identified and triaged	SOC team only
T+1h	Initial assessment — affected assets, severity	SOC manager, Security engineering
T+4h	Compensating controls deployed	SOC team, IT operations
T+8h	Patch deployment plan and timeline	CISO, IT director
T+24h	P0/P1 systems patched or compensated	Security leadership
T+72h	All affected systems patched or exceptioned	Full stakeholders
T+7d	Post-incident review	SOC team

Zero Trust Architecture — detection and response for TA0005 techniques
Active Directory Compromise Response — detection and response for T1558 techniques
Business Email Compromise Response — detection and response for T1566, T1114, T1098, T1586 techniques