To check whether you were exploited before a zero-day patch, decide the window of exposure, collect logs and system state from affected hosts, hunt for the indicators in the advisory, and look for signs of persistence such as new accounts or scheduled tasks. A patch does not remove an attacker who already has access.
Why patching is not the end
A zero-day is exploited before a fix exists. Between the first attack and your patch there may be days or weeks. Anything an attacker did in that period stays in place after the patch: web shells, new users, stolen keys, added scheduled jobs.
CISA's directive BOD 26-04 reflects this. For some entries it requires remediation or mitigation within three days and also asks the agency to triage the asset to determine whether it was compromised. That pairing is a good model for any organization.
Step 1: set the window
Pick a start and an end. The start is the earliest date the flaw is known to have been exploited, or the date the vulnerable version first ran on the host, whichever is later. The end is the moment you applied the fix or mitigation. If you cannot establish a start, use the full log retention period and say so.
Step 2: preserve before you clean
Before you reboot or rebuild, capture what you can: log files, a memory image if your team can take one, process lists, network connections and a copy of web roots or configuration directories. Rebuilding first destroys the evidence you need.
Step 3: hunt in four places
| Area | What to look for |
|---|---|
| Network logs | Connections to addresses listed in the advisory, odd outbound traffic from the affected host |
| Application logs | Requests matching the exploit pattern, errors at odd hours |
| Host state | New accounts, new services, new scheduled tasks, unfamiliar files in web roots |
| Identity logs | Logins from the affected host, token use that does not match normal patterns |
Use the indicators the vendor or government publishes. Treat a clean result as "no evidence found," not "proof of safety," because logs can be incomplete.
Step 4: decide on rebuild or rotate
If you find evidence, treat the host as compromised: isolate it, rebuild from a known good image, and rotate any credentials it held. If you find nothing but the host sat exposed and internet-facing with high-value secrets, a rebuild and rotation is still a sensible precaution. See which credentials to rotate.
Record the result
Write down what you checked, what you found and what you could not check. If personal data may have been touched, this record feeds the legal clocks described in does a zero-day trigger breach notification.
Quick check
Is a clean scan after patching proof we were not hit?
No. A vulnerability scan shows the flaw is gone, not whether someone used it earlier. You need log and host review.
Should we rebuild every exposed host?
Not always. Rebuild when you find evidence or when the host held sensitive secrets and sat openly exposed. Otherwise document why you did not.
Sources
Last reviewed: 19 October 2026.
