Zero-Day Vulnerability Response Playbook: Detection and Mitigation Before a Patch Exists

The first four hours of zero-day response are intelligence gathering. Your decisions depend on accurately understanding your exposure before you take action.

Determine if you are affected:

1. Identify all instances of the affected product in your environment: check your CMDB, vulnerability scanner asset inventory, network discovery data, and cloud inventory. Zero-days frequently affect products that appear in shadow IT or unmanaged asset inventories.
2. Confirm version and configuration scope: many zero-days have specific version ranges or require specific feature enablement. Verify whether your deployment matches the vulnerable configuration.
3. Identify internet exposure: is the vulnerable component reachable from the internet? Check firewall rules, load balancer configurations, and cloud security group rules. Internet-exposed instances are the highest priority.
4. Identify internal exposure: even if not internet-facing, the affected component may be reachable from attacker-controlled endpoints in a lateral movement scenario.

Assess exploitation status:

• Check GreyNoise for scanning activity targeting the CVE's affected ports/services
• Check Shodan for exploitation indicators in internet-wide scan data
• Check your threat intelligence platform for threat actor association (nation-state zero-days may be in targeted exploitation; criminally motivated zero-days move faster to mass exploitation)
• Check CISA KEV for formal exploitation confirmation
• Monitor vendor advisories, security researcher Twitter/X feeds (often the fastest source of exploitation evidence), and NVD for CVSS scoring and CWE classification

Assign a response tier:

• Tier 1 (Critical): Internet-exposed, confirmed active exploitation, CVSS >= 9.0 or RCE without authentication. Drop other work.
• Tier 2 (High): Internet-exposed, exploitation suspected or imminent, CVSS 7.0-8.9. Respond within 4 hours.
• Tier 3 (Medium): Internal only, exploitation possible but not confirmed, requires authentication. Respond within 24 hours.
• Tier 4 (Low): Limited exposure, post-authentication, no public PoC. Standard patch window applies.

Emergency mitigations buy time while a patch is developed and tested. Apply in order from highest impact to lowest operational disruption.

Option 1: Disable or remove the vulnerable component. The most effective mitigation: if the affected feature or product is not business-critical, disable it entirely. For a vulnerable VPN product, this may not be feasible, but for a vulnerable optional feature (authentication module, specific API endpoint, legacy protocol), disabling is often the right call. Document what was disabled and the business impact for tracking.

Option 2: Block network access to the vulnerable service. For internet-exposed services: implement WAF rules that block known exploitation request patterns (vendor or security researcher advisories often publish these within hours of disclosure), restrict source IP access to known business networks where possible, move behind a bastion host or VPN for temporary access control, and enable geo-blocking if your user base is geographically bounded.

Option 3: Add compensating authentication controls. For unauthenticated zero-days: add an authentication layer in front of the vulnerable service if architecturally feasible. Cloudflare Access, nginx auth_basic, or a VPN requirement in front of a previously public-facing service can neutralize unauthenticated zero-days.

Option 4: Apply vendor-provided workarounds. Vendors frequently publish configuration-based workarounds before patches are available. These are specific to each vulnerability — follow the vendor advisory exactly. Common workaround types: disabling a specific feature flag, restricting certain request headers, applying a vendor-provided signature to your WAF, or enabling a setting that adds input validation.

Option 5: Isolate the affected system. For systems that cannot be taken offline or have no available workaround: implement network microsegmentation to restrict what the affected system can communicate with. A compromised system that cannot reach your domain controllers, backup infrastructure, or production databases has drastically reduced blast radius.

Parallel to mitigation, deploy detection rules for known exploitation indicators. Even if you successfully mitigate the vulnerability, detecting exploitation attempts confirms whether you were targeted and provides evidence for retrospective hunting.

Sources for exploitation indicators:

• Vendor advisories: most major vendors publish IoCs and log signatures within 12-24 hours of acknowledgment
• CISA advisories: include detection guidance for KEV entries
• Security researcher advisories: Rapid7, Tenable, Qualys, and Censys publish technical analysis including exploitation signatures
• Community threat intel: Bleeping Computer, The Hacker News, and security researcher social media often have early IoC sharing
• SigmaHQ: community contributors frequently publish Sigma rules for high-profile zero-days within 24-48 hours

Deploy detection at multiple layers:

WAF/IDS layer: Add signatures for known malicious request patterns. For web application zero-days, this typically means request URI patterns, specific POST body payloads, or HTTP header combinations that appear in published PoC exploits.

SIEM layer: Create detection rules for post-exploitation activity specific to the vulnerability's likely post-exploitation path. An RCE zero-day on a web server might chain to: web shell creation, unexpected child processes spawned by the web server process, outbound connections from the web server to attacker infrastructure. Detection on post-exploitation behavior catches exploitation even when the initial exploit request evades signature detection.

EDR layer: Push hunting queries to your EDR platform for indicators of post-exploitation on affected endpoints: suspicious child processes of the vulnerable application, unexpected DLL loading, credential access tools, and network connections to uncommon destinations.

Example: Generic web server zero-day post-exploitation detection (Sigma):

title: Web Server Spawning Suspicious Child Process
status: experimental
logsource:
  product: windows
  category: process_creation
detection:
  selection_parent:
    ParentImage|endswith:
      - '\\w3wp.exe'
      - '\\tomcat.exe'
      - '\\nginx.exe'
      - '\\apache.exe'
  selection_suspicious_child:
    Image|endswith:
      - '\\cmd.exe'
      - '\\powershell.exe'
      - '\\wscript.exe'
      - '\\cscript.exe'
      - '\\certutil.exe'
      - '\\curl.exe'
      - '\\wget.exe'
  condition: selection_parent and selection_suspicious_child
level: high

Zero-day vulnerabilities frequently have a window of exploitation before disclosure — the time between when a threat actor discovered and began exploiting the vulnerability and when it became publicly known. This pre-disclosure exploitation window averaged 70 days for state-sponsored zero-days according to Google Project Zero data. Before concluding you are not compromised, hunt for pre-disclosure exploitation artifacts.

Define the hunting window: Set your retrospective hunt window based on the vulnerability type and threat actor likely to have exploited it. For nation-state zero-days: hunt 180 days back. For criminal zero-days: 30-90 days. Start from the earliest date the vulnerability could plausibly have been exploited (often estimated by the vulnerability introduction date in the software history).

Hunt for exploitation indicators in historical logs:

1. Pull all requests to the affected service from your web/application logs for the hunting window
2. Apply the exploitation signatures from vendor and researcher advisories against historical data
3. Identify unusual request patterns: abnormal request sizes, unexpected parameters, requests from unusual source IPs or geographic locations
4. Look for successful requests followed by anomalous behavior: web shell uploads, outbound connections from the server, unusual process execution

Hunt for post-exploitation artifacts: Once you have identified potentially suspicious requests, hunt for post-exploitation activity that would follow successful exploitation:

• Web shells: new files in web root directories with .php, .aspx, .jsp extensions created after the exploitation window opened
• Unexpected scheduled tasks or cron jobs created on affected servers
• Unusual outbound connections from affected servers (baselines from 90 days before the suspected exploitation window)
• Lateral movement from affected servers: authentication events, SMB connections, RDP sessions initiated from the affected system to internal hosts
• Credential access: LSASS access, SAM database access, /etc/passwd or /etc/shadow reads

If you find evidence of prior compromise: Escalate to full incident response. A zero-day exploitation that predates disclosure means the threat actor may have had access for months. Assume all data the affected system could reach is compromised. Notify legal and privacy counsel immediately for breach assessment.

Zero-day response requires fast, clear communication with multiple stakeholder groups who need different levels of detail.

Executive/board communication (T+2 hours): Subject: [CRITICAL] Zero-Day Vulnerability Response — [Product] CVE-[number]

Summary: A critical zero-day vulnerability has been disclosed in [Product], which we use for [purpose]. We are [affected/assessing exposure]. No vendor patch is available. We have [implemented/are implementing] emergency mitigations to reduce risk. Our current estimated exposure risk is [High/Medium/Low] based on [internet exposure status / exploitation confirmation status]. We are continuing to monitor and will provide an update at [time].

Technical team communication (T+1 hour): Include: CVE ID, CVSS score, affected versions, your confirmed exposure scope, specific mitigation actions assigned with owners, detection rules deployed, hunting queries running, expected vendor patch timeline, escalation criteria (what triggers full IR activation).

Customer/partner notification (if applicable): If the zero-day affects a service you provide to customers, notify them of the issue and your mitigations based on your contractual SLA and applicable breach notification laws. Coordinate with legal before sending external notifications.