[HackerNotes Ep. 197] Local Hackbots, Better Harnesses, CrowdRecon, and Race Conditions

A practical look at local AI for bug hunting, specialized agents, verification, reconnaissance, and the hardware trade-offs behind modern hackbot workflows.

October 22, 2026

Hacker TL;DR

  • Smaller models can be useful hunters when the harness gives them narrow jobs, good tools, memory, and clear checks.

  • Recon data should be organized and reusable, even when it does not immediately produce a vulnerability.

  • Verifiers are essential. A suspected SSRF, XSS, or account takeover needs proof, not just an agent's confidence.

  • Local hardware provides privacy and control, but it also brings cost, maintenance, and orchestration problems.

Intigriti CrowdRecon

Sponsored by Intigriti: Join the Waitlist for CrowdRecon!

Recon Is Useful Even Without a Finding

The episode opens with CrowdRecon, Intigriti's private-beta product for structured reconnaissance.

Most bug bounty work happens before a report exists. Researchers map domains, discover paths, identify technologies, collect requests, and build a picture of the attack surface. When that work does not lead to an accepted vulnerability, most of the value is usually lost.

CrowdRecon aims to change that by letting researchers submit useful reconnaissance to programs. The data can be reviewed, organized, and potentially rewarded depending on the program and the quality of the contribution. It is still a beta product, so the exact reward model may change. It should not be treated as guaranteed payment for every scan.

The larger idea is more important than the product itself: reconnaissance can be valuable on its own. A clean map of the attack surface, with useful context and rejected assumptions, is much more valuable than a raw list of subdomains.

Hunter takeaway: Keep recon data clean, contextualized, and actionable. A list of subdomains without explanation is noise. A mapped attack surface with explored paths and rejected hypotheses can become intelligence.

The Real Advantage Is the Harness

The episode's main lesson is simple: the model is only one part of an AI hunting system.

A single general-purpose agent has to decide what to read, which tools to use, what to ignore, when to stop, and how to prove impact. That creates many ways to fail. A better design splits the work into smaller roles:

  • reconnaissance;

  • JavaScript and source-code analysis;

  • vulnerability-specific checks;

  • long-running execution;

  • reflection and review;

  • report validation.

This structure makes smaller models much more useful. A fast model can read a large APK, inspect JavaScript, search for sources and sinks, or summarize a code path. A stronger model can then focus on the few results that appear worth investigating.

The summaries must remain traceable. If an early agent removes the line that proves a data flow, the later agent may not be able to recover it. Compression is useful only when it preserves the evidence.

Verification Turns Leads Into Findings

AI systems are very good at producing plausible explanations. That is not the same as proving a vulnerability.

A callback to an external server is not automatically an SSRF. JavaScript execution is not automatically account takeover. A suspicious parameter is not automatically injection. Each vulnerability class needs its own acceptance criteria.

A useful verifier should ask questions such as:

  • Can the SSRF reach an internal service?

  • Is the XSS reflected in an executable context?

  • Can the obtained cookie perform an action as the victim?

  • Were all required roles, endpoints, or parameters tested?

  • Is the target inside the authorized scope?

The verifier should be separate from the agent that created the finding. Its job is to challenge the result, not defend it. This can be a reflection agent, an external review agent, or a programmatic test that blocks the report until the required evidence exists.

A consistent report format also helps. Every agent can provide a summary, prerequisites, proof of concept, impact, and reproduction material. That makes the output easier to review and reduces the chance that an incomplete result reaches triage.

Specialized Agents Improve Coverage

General agents often skip useful skills. They may see a Salesforce host and never run Salesforce-specific checks. They may inspect a large JavaScript bundle but stop before reaching the interesting code.

Specialized agents solve part of this problem. A Salesforce agent can be launched across the whole recon set. A JavaScript agent can be given one job: trace sources and sinks. An authentication agent can check role and permission combinations using a defined test plan.

This also makes coverage measurable. If a skill was never invoked, that is a pipeline problem, not evidence that the target was clean.

Prompt optimization can work the same way. Build a small task set from validated reports, compare outputs, and check for regressions. The goal is not to optimize forever. A few useful tests can guide the system, after which real authorized hunting remains the most important benchmark.

Critical Thinking Podcast

Check out the CTBB Discord!

We do subscriptions at $25, $10, and $5. Premium subscribers get access to:

Hackalongs: live bug bounty hacking on real programs, with VODs available

Live data streams, exploits, tools, scripts, and unredacted bug reports

You can also find some hacker swag here.

Need a pentest? Check out CTBB Pentests.

Hack full time? Check out the Full-Time Hunter's Guild.

Caido Makes Race-Condition Testing Easier to Automate

Race conditions are difficult to test because the result depends on timing, request order, and server state. They are also easy to miss when an agent sends requests one at a time and only looks at the final response.

Caido's Replay Pipelines make this easier to model. A pipeline can send requests in a controlled sequence, synchronize their final bytes, and use HTTP/2 techniques such as Single Packet Attack when the stack supports it. WebSocket replay also brings real-time application flows into the same workflow.

The important change is not that Caido finds race conditions automatically. It gives an agent a repeatable way to create the timing conditions needed to test them. That makes race testing easier to add to a harness instead of leaving it as a manual specialist task.

A useful pipeline should still record the exact order, timing, responses, and resulting state. Without that evidence, a strange response is only a lead. The interesting targets are workflows where two requests can update the same object, consume the same one-time action, or cross an authorization boundary before the application finishes processing either request.

CSS Injection Gets More Practical

PortSwigger's research on CSS injection shows how a large exfiltration problem can be reduced through offline reconstruction.

Instead of testing every possible full token in the browser, the technique collects overlapping fragments and reconstructs possible values later. For example, fragments such as c2e, 2e1, e16, and 16a can be combined into c2e16a.

This moves much of the work from the browser to an offline script. PortSwigger reports a large reduction in the stylesheet size required for the tested token scenarios. The exact result depends on the token alphabet, candidate count, page behavior, and observable signal.

The practical lesson is not that every CSS injection can exfiltrate every secret. Payload size is not always the final limit. A technique that looked impractical can become viable when the browser collects small pieces and reconstruction happens elsewhere.

Local Hardware Is a Trade-Off

Local AI is useful when privacy, control, or client requirements matter. It can also help with modified models, on-site inference, or reduced dependence on a single provider.

The trade-off is cost and maintenance. Hardware must be purchased, configured, cooled, monitored, and kept compatible with new models. A model that fits in memory is not automatically a good model for bug hunting. A smaller model may be better for fast file analysis, while a larger model handles difficult reasoning and final review.

The hardware discussion compares NVIDIA DGX Spark systems, Mac Studio machines, and other options. The important decision is not simply which device has the most memory. It is how the device fits into the harness.

Before buying, ask:

  1. Do sensitive client data need to stay on site?

  2. Which exact agent jobs will run locally?

  3. Would several smaller machines be more useful than one large machine?

  4. Have electricity, cooling, maintenance, and software support been included in the cost?

Local does not automatically mean secure. Inference APIs still need authentication, network isolation, and sensible access controls. A local model exposed through an unauthenticated public endpoint is just another service to compromise.

Orchestration Is the Next Problem

Once several agents share a computer, the system needs resource management.

Agents should have separate roles, work queues, and result stores. One agent can claim an endpoint or parameter, but it should not overwrite another agent's work. Browser-based agents should use isolated sessions with unique names. Otherwise, agents can interfere with each other's cookies, state, or navigation.

A swarm that cannot reserve a browser, assign a target, and release a resource is not ready for reliable long-running work.

Resources

That's it for the week, keep hacking!