Zero-day exploitation is a race condition between you and the attacker: the vulnerability is being used in the wild before a patch exists. Examples in recent memory — MOVEit Transfer (CVE-2023-34362), Citrix Bleed (CVE-2023-4966), Cisco IOS-XE (CVE-2023-20198), ConnectWise ScreenConnect (CVE-2024-1709). Every one of these had hours-to-days between disclosure and mass exploitation.
Effective zero-day response is rapid and parallel: confirm the threat (vendor advisory + IOC validation), scope your exposure (asset inventory by product + version), hunt for prior compromise (the disclosure window is often after weeks of exploitation), apply virtual patching (WAF rules, NSG isolation, feature disable), then patch as soon as the fix lands. The SOP below is the playbook the SOC runs in the first 4 hours.
◈ Table of Contents
Background
CONTEXT| Phase | MITRE | Signal | Severity |
|---|---|---|---|
| Pre-disclosure exploitation (in-the-wild) | T1190 (Exploit Public-Facing App), T1133 (External Remote Services) | EDR detects post-exploitation activity without an obvious CVE; unusual process from internet-facing service | CRITICAL |
| Vendor advisory drops | — | Product, affected versions, IOC list, optional mitigation. Patch may or may not be available | CRITICAL |
| Mass scanning & mass exploitation | T1595 (Active Scanning) + T1190 | External scanning for the vulnerable endpoint signature; honeypot hits; CISA KEV addition | CRITICAL |
| Post-exploitation (existing compromise) | T1505.003 (Webshell), T1059, T1078 | Webshells, in-memory implants, persistence on patched systems (attacker got in before patch) | CRITICAL |
| Ransomware / mass deployment | T1486 (Data Encrypted for Impact) | Threat actor pivots from initial 0-day access to full ransomware deployment within days/weeks | CRITICAL |
| Source | Purpose | Latency |
|---|---|---|
| Vendor PSIRT advisory | Authoritative product / version / mitigation / patch | Hours from disclosure |
| CISA KEV catalog | Confirmation of in-the-wild exploitation; agency deadlines | Days from disclosure |
| CERT/CC, NCSC, MS-ISAC, sector ISAC | Cross-vendor context, IOC sharing | Hours-days |
| Security research blogs (Mandiant, Talos, Unit 42, MSRC, Volexity, watchTowr) | Detail, IOCs, detection logic, exploit attribution | Hours-days |
| Your CMDB / cloud inventory | Where you actually run the affected product | Must be accurate < 24h |
Identification
INVESTIGATE- 1Pull authoritative inventory: CMDB + cloud asset graph (Defender for Cloud, AWS Config, GCP Asset Inventory) for the affected product. Don't trust memory.
- 2Confirm version + configuration: Not every install of an affected product is vulnerable — some only when specific feature flags are on (e.g. Citrix Bleed only with NetScaler Gateway or AAA configured).
- 3Identify exposure surface: Internet-facing, internal-only, or both? Internet-facing instances get top priority.
- 4Identify business owner per system — you'll need them for downtime decisions.
Hunt back AT LEAST 60 days. Most zero-days that make the news have been exploited quietly for weeks before public disclosure (MOVEit, ScreenConnect, Citrix Bleed all had multi-week exploit windows before patching). If your log retention is < 60 days you'll need to escalate that retention gap.
| True-Positive Signals | False-Positive Signals |
|---|---|
| Vendor IOC hash / IP observed in your logs in the trailing 60 days | EDR matched a partial behavioural signature but exploitation pre-conditions are absent |
| Affected version + config running on internet-facing asset | Same product running, but on a patched-by-default branch the advisory excludes |
| Webshells / suspicious files on disk in product's data path post-hunt | Files exist but are legitimate vendor / customer artefacts (validate hash) |
| External scanner traffic probing the exact vulnerable endpoint | Generic recon hitting many endpoints without success |
Containment
STOP IT- 1Apply WAF rule blocking the exploit pattern from vendor advisory (request signature, header pattern, parameter shape). Confirm in next request that the rule fires.
- 2Disable the vulnerable feature if the product supports it (e.g. disable VPN feature on appliance until patched).
- 3Network-isolate: tighten NSG / Security Group / firewall to allow only specific source IPs (admin VPN, known partners) to the vulnerable service.
- 4Increase EDR sensitivity on the affected hosts; switch from block-on-detect to block-on-suspicion for relevant rules.
- 1If CVSS >= 9.0 and internet-facing and unauthenticated: Take offline immediately. Business cost of outage almost certainly less than cost of breach.
- 2Engage business owner with the trade-off: "Estimated downtime vs probable breach impact." Document the decision and approver.
- 3Preserve evidence: Snapshot disk + memory of any exposed host before changes; you may need it for forensics if prior compromise is found.
Eradication
CLEAN UP- 1Apply vendor patch through emergency change. Verify version + configuration post-patch matches the fixed-version criteria in the advisory.
- 2Even after patching, treat any pre-patch internet-facing instance as potentially compromised: rebuild from gold image rather than just patching in place when realistic.
- 3Rotate secrets the vulnerable component had access to (DB credentials, API tokens, signing keys, session cookies, MFA seeds where applicable).
- 4Re-run the IOC hunt (I2) post-patch — confirm zero matches in the post-patch window. Keep the 60-day pre-patch hunt as evidence regardless.
- 5Remove virtual patch / WAF rule only after vendor patch is verified and no detection signals persist for 7 days.
- All affected instances patched or rebuilt; version match verified
- 60-day IOC hunt complete; pre-compromise determination documented
- Secrets accessible to the vulnerable component rotated
- EDR / detection rules tuned for this vulnerability class going forward
- Lessons-learned captured (especially detection-retention & patching-velocity gaps)
Escalation
TIERS| Tier | Trigger | Action / Handoff Bundle |
|---|---|---|
| L1 → L2 | Advisory drops; product is in our inventory | Advisory link, affected versions, asset list with version data, business owners |
| L2 → IR + Engineering | Affected version internet-facing OR IOC match in trailing 60 days | Virtual patch status, prior-compromise hunt results, patch ETA |
| IR → CISO + Comms + Legal | Confirmed compromise; data possibly exposed; high public visibility of CVE | Customer comms draft, regulator pre-engagement, status page update, exec brief |
| External | Active in-progress attack beyond internal capability; sector-wide pattern | Vendor IR / DART, CISA / sector ISAC, qualified external IR firm, law enforcement if criminal |
Authorized security research & penetration testing only. Unauthorized use is illegal. Authored by Rudra Verma | Senior Security Architect | CyberHawk Threat Intel.