DivisionHex

Zero-Days, Accelerated: Our AI-Assisted Exploitation Experiences

John hendley

John Hendley

VP, Chief of Staff, Coalfire

October 22, 2026

With contributions from: Tyler Booth, Michael Raibick, and Michael Alfaro.

When Exploit Development Moves at Token Speed

We now live in a world where AI-powered tools can significantly accelerate not just the discovery of previously unknown software vulnerabilities (“0-days”), but also the development of working exploits to take advantage of them. Based on our recent experience, we estimate that AI-powered tools have reduced the time required for our experts to identify zero-day and exploit vulnerabilities by more than 90%. This acceleration has translated into real offensive capabilities, including EDR tampering and unauthenticated remote code execution in widely deployed software. What once took weeks to months of research and development, now takes hours to days of effort.

These aren’t just theoretical risks of exploitation, but vulnerabilities our team has been able to take advantage of and safely exploit in live, production environments, with research and exploit development measured in hours to days and costs in hundreds of dollars.

In this post, we seek to demonstrate (while leaving some important pieces out) how trivial it is for knowledgeable threats to accelerate zero-day discovery and exploit development using AI-powered tools. We have already used these capabilities to great effect and are underway with our own responsible disclosure processes.

Having a Setup

In Catching the Big Fish, David Lynch talks about having a “setup,” meaning the place and tools you need to do something with an idea.

“Some mornings, in a perfect world, you might wake up, have a coffee, finish meditation, and say, “Okay, today I’m going into the shop to work on a lamp.” This idea comes to you, you can see it, but to accomplish it you need what I call a “setup.” 

For example, you may need a working shop or a working painting studio. You may need a working music studio. Or a computer room where you can write something. It’s crucial to have a setup, so that, at any given moment, when you get an idea, you have the place and the tools to make it happen.” 

Anyone can ask a model to look at software and try to find bugs, but we’ve found that a connected research “setup” is what really gets the ball rolling. It lets us pursue those ideas, test them against a live target, and use what we learn to decide what to try next.

The Research Environment 

The diagram below shows the basic setup; a main CLI connected to VM management, static analysis, and dynamic analysis tooling through various MCP servers.

https://cdn.coalfire.com/prod/images/An-abstracted-overview-of-our-research-environment-setup.png
Figure 1. An abstracted overview of our research environment setup


The main CLI is where we work through questions with the AI assistant, write and build test code, and launch experiments against our lab. The MCP connections give it access to several parts of the lab:

  • VM management tooling allocates targets and restores known checkpoints so we can repeat an experiment from a clean state.
  • Static analysis tooling provides the view of the binary: its functions, references, decompiler output, and disassembly.
  • Dynamic analysis tooling provides the debugger view of the running target, which includes usermode and kernel state where relevant.

In our configuration, the VM cluster hosts the analysis environment and dynamically allocated target VMs. The specific tools can change depending on the software we’re researching. What matters most is having a place where you can inspect the target, prepare an experiment, run it, and observe the result.

Put together, this is out version of the “setup.” We can take a question we have about a specific product, build a small test, and see what happens on a live target. Having the tools and place to work allows us to act on ideas while they’re still fresh, then use those results to decide what we should try next.

Chasing an Idea

We usually start with a focused reversing question. Who can reach this interface? Where is this value checked before it gets used? We work through the evidence with the AI, following references and comparing the relevant functions. The aim is to understand sources and operations and ultimately run down our hypotheses to their logical conclusion.

From there, we can start experimenting with a small PoC. The AI can help identify structures, write parsers, or build relatively complete testing harnesses. The main interface will dispatch tasks to coding agents that build the code and launch it against a known target, starting from a clean checkpoint when needed. We use the debugger to check whether we reached the code we intended to test and what actually happened.

Successful runs still leave questions to answer. Does observed behavior support our idea? Is the result coming from the target or a mistake in our test? Can we reproduce it, and does it have the security impact we think it does? The AI can help work through those questions; however, its explanation must agree with the code and the live observations. This is why we ask agents to generate logs and evidence for every action they take during the research process. Far too often, we’ve given agents access to a kernel debugger, and they’ve used that access to manufacture proof of successful exploitation.

When a test fails or produces something unexpected, that evidence goes back into the investigation. We change the test, look at another code path, or try a different input and run it again. The results help us decide which idea is worth chasing next. Getting the most out of this process requires humans in the loop to challenge the AI’s assumptions, interpret unexpected results, and steer each iteration toward meaningful, validated findings.

Weaponizing Ideas

Recent red team engagements gave us the opportunity to apply this process to specific products and demonstrate how quickly AI-assisted research can move from an initial hypothesis to a working exploit. The advantage was not simply faster analysis: it was the ability to investigate previously unknown vulnerabilities, validate their impact, and develop novel exploit chains during an active engagement.

In one instance, with initial analysis complete and the lab already in place, we took a documented memory-safety hypothesis to debugger confirmation in approximately 45 minutes. A subsequent investigation produced independently verified code execution with SYSTEM privileges in under an hour, while a separate proposed execution chain took a little over an hour to test and validate. These were individual research milestones, not end-to-end discovery timelines, but together the work led to multiple zero-day findings in a major software product, including an unauthenticated remote code execution attack chain, in just a few days.

In a separate exercise, our team went from introducing a Windows kernel driver into the lab to discovering and fully weaponizing a zero-day in under four days. The vulnerability allowed us to tamper with and disable endpoint detection and response (EDR) capabilities. Once we understood the underlying pattern, it took only a few additional hours to identify the same weakness in four to five other kernel drivers. These were novel vulnerabilities, not recorded on any existing blocklists for known vulnerable drivers.

What This Makes Possible

Most of this research used commercially available frontier models through subscriptions costing approximately $100–$200 per month, with local models used only as needed during final-stage exploit development. The frontier models used had guardrails enabled and are accessible to anyone with a credit card. To extrapolate the cost of each vulnerability identified and exploit chain created, you’re looking at $5-$50 per vulnerability in token cost. Even substantially higher costs for locally hosted models or advanced research infrastructure are unlikely to deter well-funded nation-state adversaries or established cybercriminal groups. For a criminal operation generating tens of millions of dollars annually, or a slightly funded nation-state, an $80,000 self-hosted abliterated lab represents a modest investment. 

And for the avoidance of doubt, we strongly advocate for defenders, who need those same open weight, locally hosted models. There are too many public examples of defenders failing to achieve defensive goals from frontier models due to inadvertently tripping safeguards. The genie is not going back into the bottle, and we must give defenders every advantage possible. 

For red teams, this creates an opportunity to develop novel exploit chains during operations rather than relying exclusively on capabilities built through months of advance research and development. The same opportunity is available to real-world attackers. While AI makes vulnerability research and exploit development more accessible than ever, producing reliable results still requires experts with a background in reverse engineering, vulnerability analysis, and exploit development. That expertise is needed to ask the right questions, recognize misleading output, and independently verify security impact. Access to a computer and an AI model is not a substitute for that experience. AI amplifies expertise rather than eliminating the need for it.

DivisionHex is committed to responsible disclosure and making organizations more secure. We will share further details about these vulnerabilities and our exploit development methods once disclosure processes with the affected vendors are complete. In the meantime, the message for security leaders is to follow our guidance from our whitepaper published in April (PDF): 

  1. Be maniacal about visibility inside your environment
  2. Turbocharge your vulnerability management program
  3. Re-architect your environment to be more hostile to attackers and slow them down
  4. Automate your defenses to accelerate time to identify and contain threats

Most of all, assume you are already compromised. The next few years will be challenging, but they also present an opportunity to rapidly build resilience. At DivisionHex, we’re energized by what’s possible and committed to driving preparedness for what comes next, so we can all fear no future.

Sources and related work

This is not an exhaustive list, but these projects, papers, and tools provide useful context for the workflow described here.

MCP and tooling

AI-assisted security research