The first 72 hours after a critical vulnerability is disclosed: A checklist for organisations
In the critical vulnerabilities disclosed over the past month, attackers were either inside weeks before disclosure or started exploiting within hours of it. So the question for organisations is not "did we patch?" but "were we breached before we patched?"
With PHP2Shell, exploitation was seen on the day the patch was released. The Citrix NetScaler and BeyondTrust flaws, on the other hand, were being exploited three to seven weeks before disclosure.
First 24 hours: Find out if you are affected and stop the spread
- Find the affected systems. Search your asset inventory for the product and version. Also check container images, cloud deployments and devices that ship with the product embedded.
- Prioritise internet-facing systems. VPNs, remote access, management interfaces and web servers come first.
- Preserve evidence. Before patching or rebooting, collect logs, virtual machine snapshots and configuration backups. A post-patch investigation is only possible with this evidence.
- Patch or cut off access. Take systems you cannot patch right away off the internet or put them behind a VPN or WAF.
24–48 hours: Were you breached?
- Search for the indicators published by the vendor and researchers: file names, IP addresses, log patterns. Not finding them does not prove you are clean; Citrix and BeyondTrust both warn about this explicitly.
- Look at behaviour: web server processes spawning shells, new files in web directories, new accounts and scheduled tasks, unexplained gaps in the logs.
- Keep the log window wide. Start the investigation from the first known exploitation date, not the disclosure date. In these examples that goes back as far as seven weeks before disclosure.
48–72 hours: Clean up and contain
- If there is a compromise, or it cannot be ruled out, rebuild the device from a clean, patched image. Trying to "clean" the existing system can leave hidden persistence mechanisms behind.
- Rotate credentials. Change every password, session and API key stored on or passed through the system.
- Verify. Test that the patch actually works and that the system no longer exposes the flaw from the outside.
- Document it. Record when you noticed, what you did and what you found. If personal data was affected, assess your notification obligations under the Turkish Personal Data Protection Law (KVKK) with your legal team.
Preparing for the next one
To fit these steps into 72 hours, three things need to be in place beforehand: an up-to-date asset inventory, logs stored off the device, and a written response plan that says who does what.
How Nokta Guard can help
With our vulnerability management service we continuously monitor your internet-facing assets and quickly show which of your systems a critical advisory affects. We run post-patch verification tests, and on systems suspected of exploitation we trace the attacker through forensic examination. With a cyber crisis exercise, your team can rehearse these 72 hours before a real incident.
Related services: Vulnerability Management, Remediation Tracking and Verification, Cyber Crisis Exercise
Sources: watchTowr FAQ · Qualys · The Hacker News (PHP2Shell) · Unit 42 · Help Net Security · Rapid7 · The Hacker News (CISA KEV) · eSecurity Planet