Zero-Day Vulnerabilities: Detection, Containment, and Response

In December 2021, security researchers disclosed CVE-2021-44228, a critical remote code execution vulnerability in Apache Log4j. The CVSS score was 10.0, the maximum possible. Exploitation was trivially simple: send a specially crafted string to any log field and the vulnerable server would connect to an attacker-controlled host and execute arbitrary code.

Within 72 hours, honeypots recorded millions of exploitation attempts. Organisations that had patched were safe. Those that hadn’t, and there were many because supply chain discovery is genuinely hard, were being compromised at scale.

This is what zero-day exposure looks like in practice: not a targeted attack against a specific organisation, but a race between defenders patching and attackers scanning.

What zero-day actually means

A zero-day vulnerability is a security flaw unknown to the vendor, and therefore unpatched. The name refers to the number of days the vendor has had to fix it: zero.

The term is often used loosely to describe any newly disclosed vulnerability. Strictly speaking, it only applies while no official fix exists. Once a patch is released and applied, the zero-day becomes a patched vulnerability, though unpatched instances become the most aggressively targeted systems on the internet within hours of disclosure.

The zero-day lifecycle

Understanding the lifecycle helps you identify which phase is most dangerous and what your defences need to address.

1. Discovery: a researcher, security firm, or threat actor finds the flaw
2. Weaponisation: a working exploit is developed (sometimes before independent discovery, sometimes after)
3. Limited exploitation: nation-state actors or criminal groups use it in targeted attacks while it remains unknown to the vendor
4. Disclosure: the vulnerability is reported to the vendor, or exposed publicly through leaked tools, bug bounty disclosure, or independent researcher discovery
5. Patch development: the vendor develops and tests a fix, typically taking 7 to 90 days after coordinated disclosure
6. Patch release and mass exploitation: once a CVE is public and a patch exists, automated scanning tools begin mass exploitation within hours. Unpatched systems are the target.

The most dangerous window is between steps 1 and 5. Zero-days exploited during limited targeting (step 3) are nearly impossible to defend against, since you cannot patch what you do not know is broken. The mass exploitation phase (step 6) is more predictable and more manageable, if you have a functioning patch process.

What you can and cannot control

You cannot patch what is not patched yet. That is the defining characteristic of a zero-day: by definition, no vendor fix exists. What you can do is reduce the blast radius of a successful exploit, detect it faster, and contain it before it becomes a serious breach. These capabilities are built before the zero-day is disclosed, not during the incident.

Network segmentation

If every host in your environment can communicate freely with every other host, a single compromised machine becomes a launchpad for everything else. Proper network segmentation means a zero-day exploited against your public-facing web server cannot directly reach your database, internal admin interfaces, or Active Directory controllers.

Internet → WAF → Web Tier (port 443 only, inbound)
Web Tier → App Tier (port 8080 only, no direct internet)
App Tier → DB Tier (port 5432 only, no internet)
DB Tier  → No outbound internet, no inbound from web tier

This does not prevent the initial compromise. It contains it. An attacker who exploits a zero-day in your web server gets a foothold in the web tier. Your database, your internal tooling, and your employee directory stay out of reach.

The most common failure here: security groups and firewall rules created during initial deployment and never revisited. Over time, exceptions accumulate. Permissions drift. The “temporary” rule allowing the app server direct database access becomes permanent. Review network access rules at least quarterly.

Principle of least privilege

Application accounts should have the minimum permissions required to function. This is especially important for zero-days because exploitation often leads to code execution in the application’s process context. If that context has broad permissions, the attacker inherits them.

-- Correct: read-only access to specific tables only
GRANT SELECT ON orders, products, users TO app_readonly;

-- Wrong: administrator-level access
GRANT ALL PRIVILEGES ON *.* TO app_user;

Apply the same principle to:

• Container capabilities: a web server container should not have write access to the host filesystem
• Service accounts: a service that queries an internal API should not be able to create new users or modify billing records
• Cloud IAM roles: EC2 instances should have only the S3 buckets, Lambda functions, and Secrets Manager paths they actually need

Anomaly-based detection

Signature-based detection cannot catch zero-days by definition. It recognises known attack patterns, and a zero-day has no known signature until someone writes one after the fact.

What you need instead is behavioural detection: alerts that fire when systems behave in ways they normally do not, regardless of whether the behaviour matches a known attack pattern.

Anomalies worth detecting:

• A web server process spawning a shell: /bin/bash, cmd.exe, or powershell.exe as child processes of a Java or Node process
• Outbound network connections from an application server to an IP it has never contacted before, especially on unexpected ports
• A database server initiating external network requests (databases should never initiate outbound connections)
• Authentication events outside normal business hours for service accounts that do not operate at night
• A user account accessing thousands of records within minutes when normal behaviour is tens per hour

SIEM platforms (Elastic Security, Splunk, Microsoft Sentinel) are built to detect these patterns at scale. Cloud-native options (AWS GuardDuty, GCP Security Command Center, Azure Defender) provide behavioural detection without requiring a full SIEM deployment. Even simple rule-based alerting in existing logging infrastructure is better than no detection at all.

Immutable infrastructure

Containers and VMs rebuilt from known-good images on every deployment do not persist attacker modifications. An exploit that drops a file, modifies a configuration, or installs persistence mechanisms gets wiped on the next deployment cycle.

This is not a complete defence. An attacker who achieves code execution can still exfiltrate data or pivot to other systems before the next deployment. But it eliminates the entire class of persistence attacks that rely on modifying the compromised system in place.

For traditional server environments, configuration management tools (Ansible, Chef, Puppet) running regularly can detect and correct drift from a known-good baseline. Any file or configuration that has deviated from the expected state is a potential indicator of compromise.

Detecting active exploitation

When a zero-day affecting software you run is publicly disclosed, you need to determine whether you were exploited before you knew about the vulnerability. This retrospective analysis is often more important than immediate response.

Checking historical logs

Most zero-day exploits leave traces in existing log data. The challenge is knowing what to search for.

Log4Shell exploited a specific JNDI lookup pattern embedded in HTTP headers:

# Search historical logs for Log4Shell exploitation pattern
grep -r '\$\{jndi:' /var/log/nginx/access.log*
grep -r 'jndi:ldap' /var/log/apache2/access.log*

# Check all headers, not just User-Agent
grep -iE '\$\{jndi:(ldap|rmi|dns):' /var/log/app/*.log

After a major zero-day is disclosed, threat intelligence feeds (CISA KEV, Mandiant, CrowdStrike, GreyNoise) publish indicators of compromise (IoCs): file hashes, IP addresses, domain names, and behavioural signatures, typically within hours. Use those IoCs to search your historical logs for signs of pre-patch exploitation.

Post-exploitation indicators

Even if you cannot find the initial exploit in your logs, post-exploitation activity often leaves more distinctive traces.

Signs of active compromise to search for:

• New user accounts created via legitimate admin panels at unusual hours
• Unusual outbound connections to newly registered domains or Tor exit nodes
• Scheduled tasks or cron jobs added by non-administrative processes
• Authentication attempts across multiple internal systems from a single host in rapid succession (lateral movement)
• Large data transfers during off-hours to external destinations

Honeypots and canary tokens

A canary token is a unique identifier embedded in a sensitive location (a file, a database record, a cloud credential) that sends an alert when accessed. If an attacker compromises your system and browses your filesystem or uses your credentials, the canary fires.

Place canary tokens in:

• Configuration files containing fake database credentials
• A file named passwords.txt or backup_keys.txt in likely browsing paths
• A fake AWS access key that alerts on any attempted API call
• A database record in a table containing genuinely sensitive data

canarytokens.org provides free canary tokens for common scenarios. Embed them during normal security operations, not just during incidents.

Building a response playbook

The organisations that respond to zero-days fastest are those who already have a response process before the disclosure happens. Building a playbook during an active incident is the worst possible time.

Within 30 minutes

Immediate triage actions when a critical zero-day affecting your stack is disclosed:

1. Verify presence: check whether the vulnerable component exists in your environment using your SBOM if you have one, or run dpkg -l, pip list, npm ls, or docker images to identify installed versions
2. Assess exploitability: is the component internet-facing? Does the exploit require authentication? Does your configuration match the conditions required?
3. Check vendor mitigations: configuration changes, WAF rules, or feature flags that can reduce exposure even before a full patch is available
4. Check CISA KEV: is this vulnerability already being actively exploited in the wild?

Within 2 hours

If the vulnerability is confirmed present and exploitable:

1. Apply all available vendor mitigations, even partial ones
2. Increase logging verbosity on affected systems to capture exploitation attempts
3. Alert your security team and relevant stakeholders with a clear assessment of exposure and urgency
4. Begin reviewing historical logs for exploitation indicators if the CVE has published IoCs

Within 24 hours

Deeper investigation and formal response:

1. Confirm the vendor patch timeline: when will a full fix be available?
2. Complete historical log review for signs of pre-patch exploitation
3. If evidence of exploitation is found, initiate your incident response plan, since this is no longer a vulnerability management exercise
4. Document every action taken with timestamps for your post-incident review

After patch release

Once a fix is available:

1. Apply it promptly, outside your normal patch window if necessary, since critical zero-days warrant emergency patching
2. Verify the patch deployment: confirm the vulnerable version is no longer running in any environment
3. Conduct a retrospective: how did you learn about this disclosure? How quickly could you determine whether you were affected? What would have changed if you had been exploited before learning about it?

Threat intelligence sources

Zero-days disclosed through coordinated vulnerability disclosure reach defenders and attackers simultaneously. The advantage goes to the team that responds faster. Subscribing to the right intelligence sources closes the gap.

Essential feeds

• CISA KEV (cisa.gov/known-exploited-vulnerabilities-catalog): CVEs with confirmed active exploitation. US federal agencies are legally required to patch these within strict deadlines, but the list is public. Any entry affecting your stack requires immediate action.
• NVD (nvd.nist.gov): the National Vulnerability Database. Subscribe to the CVE feed filtered to your technology stack for email notifications on new disclosures.
• Vendor advisories: every major vendor publishes security advisories. Subscribe for email alerts from Microsoft (Patch Tuesday), Adobe, Apache, your Linux distribution maintainers, and your cloud provider.
• GreyNoise: shows internet-wide scan activity in real time. After a critical CVE is disclosed, GreyNoise shows within hours how many scanners are actively searching for vulnerable systems and whether your IP range has been targeted.

Common mistakes and misconceptions

Most organisations approach zero-days in a way that misidentifies where the actual risk lies.

Treating zero-days as inevitable and unmanageable

The instinct is to accept zero-days as an external threat and wait for the vendor to ship a fix. This misses where the real damage comes from.

Most zero-day damage comes not from the initial exploitation but from delayed detection and slow containment. An attacker who compromises a system through a zero-day has a foothold. What they do with that foothold in the hours and days before detection determines the actual impact.

An organisation with network segmentation, least-privilege service accounts, behavioural monitoring, and an active incident response process will detect, contain, and recover from the same zero-day that causes a catastrophic data breach at an organisation without those controls.

Relying solely on perimeter defences

A Web Application Firewall can block known zero-day patterns and vendors often release virtual patches quickly. But WAF rules are written reactively. A zero-day that uses a novel technique, targets application logic rather than predictable input patterns, or arrives via a protocol the WAF doesn’t inspect will bypass it entirely.

Perimeter defences reduce your exposure. They are not a substitute for internal controls, detection capability, and a response process.

Skipping the retrospective

After resolving a zero-day incident, or after successfully patching without exploitation, teams typically move on immediately. The retrospective is skipped.

The retrospective is where you learn whether your detection would have caught active exploitation, how quickly you would have known you were affected, and what controls would have contained the blast radius. Without it, the same gaps exist in the next incident.

Schedule a retrospective within 48 hours of resolving every significant zero-day response, whether exploitation occurred or not.

The controls that matter

The controls that limit zero-day damage are identical to the controls that limit the damage of every other attack:

• Good network architecture that assumes breach at the perimeter
• Tight permissions that limit what any compromised process can do
• Behavioural monitoring that does not depend on known signatures
• Fast, practised patching that does not require heroics

Build those before you need them. Zero-days reveal whether your security posture holds under pressure. They do not create the posture.

---

HackproofHacks provides security monitoring with real-time CVE alerting for your specific technology stack. View our monitoring service or contact us to discuss your setup.