I just read one of the best writeups on autonomous vulnerability hunting I've come across: ZephrFish's 'Bullying LLMs into submission to find 0days at scale'. The post details a full-blown research lab with 8 MCP servers across 5 VMs, 300+ tools, and a pipeline that has produced multiple Go standard library CVEs, an OEM SYSTEM code execution chain, and several macOS findings. But the architecture wasn't what impressed me most. It was the hallucination bin.
The Problem: LLMs Lie Confidently
In ZephrFish's early system, LLM-driven analysis generated 'confident-sounding assessments that may or may not reflect reality.' Six findings in one session looked promising in logs and decompilation output. All six were disproven in dynamic analysis. Every single one. This is the fundamental problem with using LLMs for security research: they generate findings that look real, sound real, and are completely wrong.
The Solution: Guilty Until Proven Innocent
The single most important design decision: every finding starts as a hallucination. Not in findings/, in hallucinations/. It only gets promoted after passing four validation gates. Gate 0: PoC exists and compiles. Gate 1: PoC reproduces in a clean VM snapshot. Gate 2: Crash is exploitable (not just a null deref or graceful exit). Gate 3: Bug triggers as a standard user, not SYSTEM or admin. I've implemented this in our Sentinel scanner framework. Every finding from every scanner starts in 'hallucination' status and must be promoted through each gate with notes and timestamps.
Gate 3 is the Career Saver
Gate 3 deserves special attention. ZephrFish's worst early example: a hardware vendor's diagnostic agent was flagged as having an exploitable named pipe. The analysis ran from SYSTEM context. From a standard user, the pipe was unreachable. This happens in web bug bounty too. An endpoint that's exploitable with admin cookies but not with regular user cookies. A file upload that works in a test environment but gets blocked by the CDN in production. Always verify from the lowest privilege level that a real attacker would have.
ROI-Driven Target Selection
The second insight that changed how I think about hunting: Expected ROI = conservative payout estimate / estimated hunt hours. Use the MINIMUM from each program's published range, not the typical or maximum. Apply competition multiplier: very high competition (Chrome, Windows kernel) drops to 20% of face value. Low competition (OEM agents, enterprise middleware) keeps 90%. Apply known defence penalties: WAF drops value by 30%, rate limiting by 10%. The sweet spot is under-scrutinized software with decent bounties. That OEM update service 0-day in the blog was a direct product of this ranking.
TokenBurn: Know Your Actual Spend
ZephrFish built TokenBurn to track LLM token usage and compare API-equivalent costs against the subscription. I adapted it for our pipeline. Our numbers over 8 days of active hunting: $1,622 in API-equivalent costs vs $53 subscription cost. That's a 30.4x savings multiplier on Claude Max. The cost-per-finding metric matters more: total compute cost divided by validated findings (not hallucinations, only findings that survived all four gates). Most campaigns produce zero validated findings. The ones that do produce findings often took less time, because the knowledge loop steered them toward targets with higher prior probability.
The Knowledge Loop
Before each hunt: query past findings. Have we seen this pattern before? What techniques worked? What defences blocked us? After each hunt: record the outcome. The next hunt starts with richer context. After 15+ campaigns, ZephrFish reports that the system's recommendations are measurably better than cold-starting each time. The RAG queries prevent the most expensive mistake: running the same campaign against the same binary with the same approach and getting the same nothing.
What I Built
Integrated into our Sentinel continuous scanner: (1) Hallucination bin with 4 promotion gates and full audit trail. (2) ROI calculator covering 18 vulnerability classes with competition and defence adjustments. (3) Target ranking based on port diversity, subdomain count, existing findings, WAF presence, and exposed paths. (4) TokenBurn cost tracker parsing Claude Code session data with per-project and per-model breakdowns. (5) Cost-vs-subscription comparison showing actual ROI on the Claude Max investment.
The Honest Take
As ZephrFish says: the hallucination bin is larger than the findings directory by a significant margin, and that's working as intended. It means the system catches its own false positives before they waste time. The real value isn't any single finding. It's the compounding: each campaign makes the next one more efficient. The knowledge loop, the defence database, the ROI scoring, they all compound. That's what makes this approach viable long-term.
Source: blog.zsec.uk/bullyingllms by Andy Gill (ZephrFish). TokenBurn: github.com/ZephrFish/TokenBurn.
No comments yet