Scanning and exploitation methodology

Scope is enforced, not remembered

Every engagement begins with scope, and scope is enforced by the platform rather than by the operator remembering what is in bounds. Targets are defined before a scan starts. Running an offensive platform against a system you do not own or have written permission to assess is a criminal offence in most jurisdictions, and automation changes nothing about that.

This matters more for an exploiting platform than for a scanner. A scanner that strays out of scope produces an unwanted request. A platform that strays out of scope produces an unauthorised intrusion.

The four phases

A scan moves through four phases. The boundaries matter because each phase produces the context the next one depends on.

1 · Configure

Point at a URL or a codebase, choose a profile, set scope. Stack fingerprinting runs here, and smart selection reduces 290+ modules to the subset that can plausibly apply.

2 · Scan

The five layers run in parallel with rate limiting and circuit breakers. Progress streams live rather than appearing at the end, so a scan that is going wrong can be stopped while it is going wrong.

3 · Exploit and prove

Offensive modules and AI-guided steps confirm each candidate finding and capture reproducible evidence. A finding that cannot be proven is reported as unproven rather than quietly promoted.

4 · Report

Findings are correlated across layers, prioritised, and exported as branded HTML for the client plus JSON and SARIF for the pipeline.

Guardrails on exploitation

Automated exploitation without constraints is a production incident waiting to happen. Four mechanisms bound what a scan can do.

Command gate

Every command generated during AI-assisted exploitation passes through a security gate before execution. Destructive or out-of-scope commands are rejected by default rather than allowed unless blocked.

Rate limiting

Request rates are capped so a scan degrades a target's performance as little as possible. This is what makes production testing viable at all.

Circuit breakers

Repeated failures halt the affected branch instead of hammering a service that has already stopped responding.

Per-node watchdog

In pipeline runs, each node carries its own timeout so a single hung step cannot freeze an entire scan.

What counts as evidence

The distinction between a scanner and a platform that proves comes down to what lands in the report. Koruqan treats a finding as proven only when it carries an artifact a reader can evaluate independently: captured command output, a file that should not have been readable, a database row that should not have been reachable, a session that should not have been obtainable.

Blind vulnerability classes cannot produce direct output by definition. For blind SSRF and blind RCE, confirmation runs out-of-band through interactsh: the payload triggers a callback to a controlled endpoint, and the callback is the evidence.

AI validation sits alongside this rather than replacing it. Gemini produces the executive summary, priority ranking, remediation roadmap and false-positive flags, and every AI verdict is cached into the report so a reader can see what the model concluded and why. The model does not decide whether an exploit succeeded — the success check does.

Correlation across layers

Findings are linked rather than listed. A hardcoded credential found by a static module, the same credential accepted by the live login, the database reachable once authenticated, and the escalation path from there are one attack path, not four findings.

This is the part that is hard to do and easy to skip. A platform that reports SAST results and DAST results in separate lists has left the correlation work to the reader, which is the most expensive part of the engagement.

Keeping intelligence current

Version detection is only useful against current vulnerability data. Detected component versions are matched against CISA KEV, NVD, GHSA and EPSS, which reorders remediation by real-world exploitation rather than CVSS alone. A Tenable Nessus bridge pulls existing Nessus findings into the same correlated report, so an organisation already running Nessus does not end up with two disconnected views of the same estate.

A methodology knowledge base is built from disclosed HackerOne reports, which enriches findings with the context real attackers used against comparable systems.

Output formats and why both exist

Two audiences need two formats. The branded HTML report carries AI commentary, a hardening plan, root-cause analysis and a scan-to-scan diff showing what is new and what has been fixed — this is what goes to the client or to leadership.

JSON and SARIF exist for the pipeline. SARIF in particular lets findings surface in an existing code scanning UI and lets a build be gated on severity thresholds. A platform that only produces a PDF cannot gate a build.