What is Zero-Day?

Three terms get used as if they were one. The zero-day vulnerability is the flaw itself, for example a SQL injection in a file transfer product. The zero-day exploit is the code or request sequence that turns the flaw into access. The zero-day attack is the use of that exploit against real targets. Each leaves different evidence: a vulnerability shows up in an advisory or a scanner report, an exploit in a payload or a crash, an attack in your own logs.

Definitions differ on one point. The older one says the vendor does not know about the flaw. Google Threat Intelligence Group (GTIG) counts any vulnerability maliciously exploited in the wild before a patch was publicly available, which includes flaws the vendor knew about and had not fixed yet. On that definition GTIG tracked 90 zero-days in 2025, up from 78 in 2024 and inside the 60 to 100 range of the previous four years. 43 of them (48%) hit enterprise products, an all-time high, and about half of those were security and networking products such as VPN gateways and firewalls. GTIG also points out that most edge devices run no EDR, so when one is compromised defenders have little host evidence to work with.

The timeline of a real one, MOVEit Transfer (CVE-2023-34362), shows where the SOC fits. Mandiant's earliest evidence of exploitation is May 27, 2023: SQL injection, then an ASP.NET web shell named human2.aspx, imitating the legitimate human.aspx, and in some cases data theft within minutes. Progress announced the vulnerability on May 31. NVD published the CVE on June 2, and CISA added it to the Known Exploited Vulnerabilities (KEV) catalog the same day. For at least four days the flaw was being exploited and no advisory existed. Organizations hit in that window had no patch to apply, so detection was the only control they had.

What the SOC does while there is no patch, in the order it usually happens. Scope exposure first: find every instance of the affected product and version, internet-facing ones first. A software inventory or SBOM answers that with a query instead of a round of emails, and GTIG recommends keeping one for exactly this reason. Apply the vendor's workaround next. Advisories for exploited flaws often ship a stop-gap before or alongside the fix, such as disabling a feature or closing a port at the perimeter, and GTIG's guidance for unpatched systems is the same: isolate them with stop-gap measures. Then watch KEV, the catalog of vulnerabilities with confirmed exploitation. CISA mirrors its data files on GitHub (cisagov/kev-data); each entry carries dateAdded, requiredAction, and knownRansomwareCampaignUse, and the 2026-10-08 release lists 1,739 vulnerabilities. A daily join of KEV against your asset inventory catches the flaws that move from rumor to confirmed overnight.

Then hunt by behavior, because on day one there is no hash to match and no IDS rule to fire. There is behavior the exploit has to produce. A web shell dropped through a vulnerable web application lands as a new script file written by the web server process, and that is visible without knowing the malware's name. In Microsoft Defender for Endpoint advanced hunting:

DeviceFileEvents | where Timestamp > ago(30d) | where InitiatingProcessFileName =~ "w3wp.exe" | where FileName endswith ".aspx" | project Timestamp, DeviceName, FolderPath, FileName, SHA256, InitiatingProcessCommandLine

On a stable IIS server this returns very little. Deployments write .aspx files too, so check each hit against the change calendar. An .aspx file written outside a deployment window, with a name that imitates a legitimate file in the same folder (human2.aspx next to human.aspx), is a web shell until proven otherwise. Finally, look back. When the advisory lands, search the logs you kept from before the disclosure date for the published indicators, because exploitation that started before May 31 only shows up in history.