The Zero-Day Exploit Clock Is Ticking

A Personal Introduction

The notion of breaking into a system and making it do something its developers never intended has existed since the early days of computing. My own introduction to computing came through hacking into games — disabling or increasing the number of lives to compensate for my slow reflexes.

Using TD (Turbo Debugger, from Borland — shipped alongside Turbo Assembler and Turbo C/C++), I would painstakingly try to identify the memory location that held the lives counter. Once found, one could either alter the value directly or place a NOP (No Operation) over the conditional jump. It was a task that required patience, determination, and, many times, reams of sprocketed continuous-feed paper annotated to help decipher what the code did.

Discoveries were rarely kept to oneself. You shared them with others on BBSs (Bulletin Board Systems), the dial-up communities that served as gathering places for the technically curious long before the web existed.

BBSs were not just a place to share results; they were a primary source of knowledge. Text files on cracking techniques, annotated memory maps for popular games, and tutorials on x86 assembly circulated freely between boards. You would dial in with a modem, download a collection of .TXT and .NFO files, then spend hours offline studying them. It was a decentralised, informal education system: no textbooks, no courses, just collective knowledge passed between pseudonyms.

The motivation was curiosity. There was no financial incentive and no criminal intent. It was intellectual challenge for its own sake — the digital equivalent of picking a lock just to prove you could.

From Annoyance to Destruction

That harmless hacking eventually evolved into something darker: worms, trojans, and viruses. Initially, these programs were little more than an annoyance, displaying messages on screen or slowing machines down. But the lever was gradually notched towards the harmful and destructive. Rather than simply popping up a message, these programs began deleting files and formatting hard drives.

Early examples like the Brain virus (1986) were relatively benign; it even included the authors' names and phone number. But by the early 1990s, destructive payloads had become common. The Michelangelo virus (1992) overwrote the first hundred sectors of a hard disk. CIH/Chernobyl (1998) went further, attempting to corrupt BIOS firmware and render machines unbootable.

If you are interested in watching a YouTube video of mine from 19 years ago demonstrating the operation of a destructive virus called “Casino de Malte”, head over to https://youtu.be/wiLZAEMsofM. Your hard disk’s fate was determined by the outcome of a game.

The Commercialisation of Hacking

The internet, cryptocurrency, and the dark web created an environment in which malicious actors could come together and organise themselves into profit-seeking entities. Their business model: penetrate systems, steal data, hijack operations, and then seek payment from the victim to rectify the mess they created.

It proved extraordinarily lucrative. Cybercrime is now measured in the trillions. Cybersecurity Ventures estimated that global cybercrime damage would reach $10.5 trillion annually by 2025 — a figure that, if treated as an economy, would make cybercrime the third-largest in the world after the United States and China.

These are not lone hackers in basements. Modern cybercriminal organisations operate with corporate structures — complete with HR departments, customer service teams to “help” victims pay ransoms, software development lifecycles, and even employee performance reviews. Groups such as LockBit and Conti have operated as Ransomware-as-a-Service (RaaS) platforms, licensing their tools to affiliates in exchange for a percentage of the ransom collected.

The Ecosystem: States, Criminals, and Brokers

Today, the malware market is made up of three distinct layers:

• State-backed groups — Advanced Persistent Threat (APT) actors funded by nation-states for espionage, sabotage, and geopolitical advantage. Examples include Fancy Bear (Russia), Lazarus Group (North Korea), and APT41 (China).
• Private criminal groups — Organisations that carry out penetration attacks, deploy ransomware, and operate data-theft schemes for profit.
• Exploit brokers — Companies and individuals that trade in hacking knowledge. Firms such as Zerodium openly advertise bounty prices for zero-day exploits: up to $2.5 million for a full Android exploit chain, for example. This grey market means that vulnerabilities are sometimes sold to the highest bidder rather than reported to the vendor for patching.

The success of these operations often depends on what are known as zero-day exploits: vulnerabilities in software that are not yet publicly known and for which no patch or mitigation exists. The term “zero-day” refers to the fact that the vendor has had zero days to fix the problem before it is exploited.

To complicate matters further, some attacks require chaining together multiple exploits in a particular sequence. This is known as an exploit chain, or attack chain. For example, a modern browser exploit might chain a renderer vulnerability with a sandbox escape and a kernel privilege escalation — three separate flaws linked together to achieve full system compromise.

The Zero-Day Exploit Clock

The website “Zero Day Clock” presents a striking visualisation. It analyses publicly known vulnerabilities and estimates the time between public disclosure of a vulnerability and the first confirmed exploitation in the wild.

CVE gives a publicly disclosed vulnerability a common identifier, but it is only one part of the vulnerability-tracking ecosystem. CWE describes the underlying weakness, CVSS scores technical severity, EPSS estimates exploit likelihood, and CISA’s Known Exploited Vulnerabilities catalogue highlights flaws already exploited in the wild. Together, these systems help organisations decide what to fix first.

Strictly speaking, once a vulnerability is publicly disclosed, it is no longer a zero-day in the narrowest sense; exploitation after disclosure is often described as n-day or one-day exploitation. But from a defender’s point of view, the practical effect is similar: the available response window is collapsing.

The trend is alarming:

That compression — from months to days, and potentially from days to minutes — represents a fundamental shift in the threat landscape. Defenders used to have time to test, prioritise, patch, and monitor. Increasingly, they may have only hours, minutes, or seconds.

The AI Accelerant

The dramatic reduction in exploitation time is being accelerated by artificial intelligence, but AI is only one part of a wider shift. Automated scanning, exploit marketplaces, faster reverse engineering, criminal collaboration, and global infrastructure have all compressed the defender’s response window.

The same AI tools that security researchers use to find flaws in code can also be weaponised by adversaries. Their systems can continuously scour vulnerability databases, security mailing lists, vendor advisories, and even social media for news of a newly disclosed weakness. Once alerted, AI-assisted tools can help to:

• Analyse the vulnerability — parsing patch diffs to understand exactly what was fixed and, therefore, what was broken.
• Generate exploit code — assisting with proof-of-concept attacks targeting the flaw.
• Adapt and mutate — creating variants that may evade simple signature-based detection.
• Scale deployment — scanning the internet for unpatched systems and deploying attacks at machine speed.

This is no longer theoretical. Academic research has shown that AI agents can exploit some real-world vulnerabilities in controlled benchmark environments. The barrier to entry has lowered: what once required deep expertise in assembly language and months of reverse engineering can now, in some cases, be partially automated.

AI is also being used offensively for:

• Spear-phishing at scale — generating personalised, convincing emails that bypass traditional spam filters.
• Deepfake social engineering — cloning voices and video to impersonate executives in business email compromise (BEC) attacks.
• Automated reconnaissance — mapping an organisation’s attack surface faster than any human team could.

What Can We Do?

We cannot eliminate risk, but we can significantly reduce our exposure.

For individuals:

• Keep all devices updated with the latest security patches, and enable automatic updates wherever possible.
• Retire technology that is outdated and no longer receiving security updates. End-of-life software is an open door.
• Use multi-factor authentication or passkeys on every account that supports them.
• Be sceptical of unexpected communications, even from known contacts. Verify through a separate channel.
• Avoid reusing passwords. A single compromised password can become the first link in a much larger chain.

For organisations:

• Maintain a rigorous patch management programme. The window between disclosure and exploitation is shrinking towards zero. That means patching can no longer be treated as a slow administrative process. Organisations should:
  • Automate patch deployment where the risk profile allows it, especially for standard operating systems, browsers, endpoint software, and widely deployed services. Human approval remains important for high-impact systems, but approval workflows measured in days do not match a threat landscape measured in minutes.
  • Prioritise vulnerabilities based on exposure, exploitability, business impact, and evidence of active exploitation. If twenty fixes are waiting, the most exposed and most exploitable systems should move first.
  • Maintain an emergency patching route for critical vulnerabilities, with pre-agreed ownership, testing boundaries, rollback plans, and communication paths. The middle of an incident is the wrong time to decide who is allowed to approve a fix.
• Prioritise internet-facing systems and known exploited vulnerabilities. These are the systems attackers can reach first and the weaknesses they are most likely to weaponise quickly.
• Adopt a zero-trust architecture: assume breach and verify every access request.
• Invest in defensive tools that can detect, prioritise, and respond at machine speed. Alerts alone are not enough; the goal should be rapid triage, containment, and recovery.
• Conduct regular penetration testing and red-team exercises. These should test not only whether vulnerabilities exist, but whether the organisation can detect, escalate, and respond to them quickly.
• Ensure robust, tested backup and recovery procedures. Ransomware is only effective if you have no viable alternative.

The uncomfortable truth is that vigilance alone is no longer sufficient. When exploitation timelines compress to minutes, human reaction time becomes the bottleneck. Organisations need automated detection, prioritisation, containment, and recovery capabilities that can operate at the same speed as the attacks they face.

We must also recognise that each of us can be one link in an exploit chain. A compromised personal device, a reused password, an unpatched home router — any of these can become the entry point that leads to a larger organisational breach.

Closing Thought

In three decades, hacking has evolved from teenagers on BBSs trading game cheats into a global criminal industry: commercialised, professionalised, backed by nation-states, and now accelerated by artificial intelligence.

The zero-day exploit clock is ticking faster than ever. For individuals, that means patching, retiring obsolete technology, using passkeys or multi-factor authentication, and treating unexpected communication with caution. For organisations, it means accepting that manual response is no longer enough.

The question is no longer whether an attack will come, but whether our defences can respond in the seconds we may have left.

Suggested references

• Zero Day Clock: https://zerodayclock.com/
• Cybersecurity Ventures, 2025 Official Cybercrime Report: https://cybersecurityventures.com/official-cybercrime-report-2025/
• CVE-Bench: https://arxiv.org/html/2503.17332v3

 

---

 

Follow This, That and (Maybe), the Other: