Skip to content

Scan options ​

Field-by-field reference for the New Scan wizard and host tool tabs: shared Options / Throttling & Limits, then Nikto-only modules, reject filters, MS10-070, and JWT.

For how to open the wizard and start a scan, see Scans. Crawl-only knobs are on Web Crawler. Bustah-only knobs are on Bustah. LFIC uses the same shared panels on New LFIC Scan and the host LFIC tab — see LFIC.

Scan option defaults ​

Many fields on the New Scan wizard and host tool tabs can be pre-filled from stored defaults. Precedence at launch:

values on the scan form  >  host Scan Defaults  >  project Scan Defaults

Explicit choices on the scan form always win. Stored defaults only fill fields the scan left unset.

Shared scan options (Nikto, Crawl, LFIC) ​

Nikto, Crawl, and LFIC share a common options model. In the New Scan wizard, on New LFIC Scan, and on the LFIC host tab, identity and throttle knobs render once on the Options and Throttling & Limits tabs — not duplicated on each tool panel.

Boolean toggles (per tool tab) ​

OptionNikto defaultCrawl defaultLFIC default
Follow RedirectsOffOffOff
Send Browser HeadersOnOff (browser sends its own)Off
Secret DetectionOnOnOn
Force IPv6OffOffOff

Secret Detection inspects response bodies for exposed credentials (API keys, tokens, private keys) and reports them as informational findings. Matching runs offline; matched values are stored unredacted so you can identify and rotate leaked keys. It is on by default for every tool. What gets inspected is scoped per tool: a Bustah sweep inspects only its retained hits, and an LFIC scan inspects only the content of the files it actually retrieved — never every probed path, and never the vulnerable page's own HTML wrapper. On the LFIC tab the checkbox sits with the other file-retrieval options, directly below Include Binary Executables.

Force IPv6 requires an AAAA record and IPv6 egress; scan creation fails with no IPv4 fallback. Grayed out when the deployment has no IPv6 egress.

Options tab (identity) ​

FieldBehavior
User-AgentSent on outbound requests. On a Headless crawl it replaces the browser's own unless Header Mode keeps it.
Virtual HostA hostname, optionally :port. No credentials, path, query, or spaces — the field says so if the value is not a host. Overrides the site name while connecting to the target's real address. Nikto/LFIC/Bustah: Host header only (SNI unchanged). Crawl: fully coherent only with Standard-only engine — see crawler guide.
Root PathPrefix every request path (for example /app). Bustah ignores this — use Base path on the Bustah tab.
Additional HeadersExtra headers, one per line as Name: value. Project enforced headers merge in and cannot be removed here. Host in additional headers is rejected on crawl scans.

Blank fields inherit from host Scan Defaults, then project Scan Defaults.

Project headers shortcut

If the project has headers configured, a Set Project Headers button appears next to Additional Headers to copy them into the field. Enforced project headers are shown separately as read-only — they are always applied and cannot be edited here.

Throttling & Limits tab ​

FieldBehavior
ConcurrencyMax simultaneous requests. Blank = project/global default.
RPSMax requests per second (0 = unlimited). RPS and Delay both pace traffic — the stricter binds.
DelayFixed milliseconds or a jitter range (for example 50-200).
Host timeout (min)Scanning-time cap (0 = no limit). Paused idle time does not count.
Max concurrent hostsBulk launches only — cap parallel Nikto, Crawl, LFIC, and Bustah scans.
ProxyRoute traffic through a stored proxy. Enforced project proxy wins and locks the selector. HTTP/3 on Nikto conflicts with any proxy — see HTTP/3.

Crawl-only: Header Mode ​

On the Crawl tab, Header Mode controls how Options tab User-Agent and Additional Headers combine with the browser's own headers on Headless traffic:

ModeBehavior
Add to browser headers (default)Layer your User-Agent and headers on top of the browser's
Replace browser headersSend only your headers except a preserved set (Host, Cookie, Content-Length, …). Blank User-Agent keeps the browser's

Project-level enforced Host headers still apply to crawl wire traffic (connection target and SNI stay on the real host).

Nikto options ​

The Nikto tab in the wizard (or host Nikto tab → New Scan) has three collapsible sections: Options (toggles and Nikto-only fields), Reject Filter, and Modules. Cross-tool identity fields live on the wizard's shared Options tab; throttle and proxy live on Throttling & Limits.

Options (Nikto tab) ​

OptionWhat it does
Follow RedirectsFollow HTTP redirects instead of treating them as the result. Off by default.
Send Browser HeadersSend browser-like headers with requests. On by default for Nikto.
Secret DetectionScan response bodies for exposed credentials and report informational findings. On by default for every tool — Nikto, LFIC, Crawl, and Bustah. Clear the box to opt a scan out.
Force IPv6Require this scan to use the target's AAAA address. Scan creation fails if there is no AAAA record or if this deployment has no IPv6 egress. No fallback to IPv4. Grayed out when IPv6 egress is unavailable — see IPv6 targets.
HTTP/3 (QUIC)Force every request in this Nikto scan over HTTP/3 (UDP/QUIC). LFIC and Bustah honor the same setting from Scan Defaults; crawl never uses QUIC. HTTP/3 cannot use a proxy — clear Proxy on Throttling & Limits, or confirm a bypass if the project enforces one. See HTTP/3 scanning.
Max retry attemptsOverride project/global retry count. Blank = inherit.
Scan failure thresholdOverride how many consecutive transport failures start the unreachable-host check. A live host is slowed, not aborted — see Settings. Blank = inherit (default 75).
Request timeout, secondsOverride how long one request may take before it counts as a failure (1–600). Blank = inherit (default 15). See Settings.
LFI DepthHow many ../ levels to use in directory-traversal tests. Range 1–20, default 8.

User-Agent, Virtual Host, Root Path, and Additional Headers are on the wizard's shared Options tab. Concurrency, RPS, Delay, and Proxy are on Throttling & Limits.

Enforced settings apply

If the project has an enforced proxy, enforced headers, or enforced throttle, those are applied regardless of what you set here. Enforced values appear in the panel as read-only (marked enforced) so you know they are in effect. See Settings → How enforcement resolves.

Reject Filter ​

Suppress noise by discarding responses that clearly mean "not found":

  • Reject Codes — comma-separated HTTP status codes to reject (for example 404,410). Must be integers.
  • Reject Regex — a regular expression; responses matching it are rejected (for example Not Found|does not exist).

Findings matching either rule are always rejected. Invalid codes or an invalid regex are flagged inline and block launch until fixed.

Modules ​

The list of available Nikto modules, each with a short description. All modules are selected by default. Use Select all / Clear all, or toggle individual modules, to control which checks run.

Some modules note recon modules they work best alongside. If one is not selected, a hint says the module "runs broader/slower without" it, plus an Enable button to add the recommended module. Modules that require another module show a red hint with Enable — without the dependency they produce no results.

Notable modules beyond the default set:

ModuleWhat it does
JWTDetects JWT-shaped tokens in responses (and scan credentials), decodes header/payload claims, reports proven misconfiguration findings, and queues scoped active probes (unverified signature, alg:none, embedded JWK) when safe. See JWT module.
FaviconFingerprints the site's favicon MD5 against an expanded dataset to identify product/firmware.
MS10-070ASP.NET padding-oracle detection — see MS10-070.
Cloud Storage ListingDetects anonymous S3 / Azure Blob object listings. See Cloud Storage Listings.

MS10-070 (ASP.NET padding oracle) ​

The MS10-070 module is a reactive check for ASP.NET padding-oracle vulnerabilities in WebResource.axd / ScriptResource.axd handlers. It does not send its own upfront probes — it watches responses from other modules (especially core) for ASP.NET pages that expose an encrypted d= token.

When a candidate appears, the scanner sweeps the last byte of the ciphertext block through all 256 values. One distinguishable "good padding" response among uniform rejections confirms a live CBC padding oracle.

UI controlBehavior
MS10-070 module checkboxInclude the module in the scan (on by default with Select all).
MS10-070 Active Confirm / ExploitOptional sub-option (only when the module is checked). Runs active confirmation: byte-by-byte decryption of a ciphertext block through the oracle. Issues thousands of extra requests to the target. Off by default.

With active confirm disabled, a positive oracle detection still produces a finding but notes that full decryption was not attempted. The platform also emits a recommendation to run the confirmation — see Confirming a candidate below.

With active confirm enabled, the scanner actively confirms the oracle and may attempt further exploit phases. Those extra oracle requests still honor the scan's RPS / throttle — they do not burst past the host limit.

Exploit phases, in order: decrypt a ciphertext block, then forge a request for a file and decode what the handler returns. A successful web.config read produces a critical finding naming the recovered machineKey. Where the target's filters block the forged request, the finding says so and still reports that the oracle itself is exploitable — a blocked file read is not a clean result.

A scan running with the sub-option on is tagged with a red MS10-070 exploit badge in the scan list, and the module reads as MS10-070 oracle in Active Jobs.

Candidates found without Nikto ​

A crawl or Bustah response that references WebResource.axd or ScriptResource.axd with a d= token raises an info finding marked candidate unconfirmed. Patched servers serve the same handler and the same token, so the reference alone is not a vulnerability — it is the signal that the check is worth running.

Confirming a candidate ​

An MS10-070 candidate — from Nikto or from a crawl — raises a runnable recommendation. Run on that row launches a new Nikto scan against the same target with the MS10-070 module and Active Confirm / Exploit enabled, after a confirmation dialog, and links to the scan it started.

The re-scan runs under the originating scan's settings: same project and target, same enforced proxy and headers, same throttle, same scope checks. It is seeded with the candidate URL, so it probes that handler instead of repeating a full Nikto scan. It is the only recommendation with a working Run; see Recommendations.

The finding describes impact: decryption of ASP.NET-protected values (ViewState, auth tickets), potential web.config read via ScriptResource, and machineKey exposure leading to remote code execution on vulnerable, unpatched servers. Remediation is the MS10-070 framework patch plus uniform error handling and machineKey rotation.

JWT module ​

The JWT module runs passively during Nikto scans (and analyzes JWTs pasted into scan credentials). When a JWT-shaped value appears in a response header, cookie, body, query string, fragment, or captured crawl request header, the module:

  1. Emits a JWT observed and decoded finding with the decoded header and payload. The compact token stays in finding detail. The same token on many pages stays one finding; pages accumulate on seen_on — see JWT findings.
  2. Adds a JWT observed; investigate the token further by hand recommendation (Manual only). Evidence names where the token was seen, the trigger, the decoded header and payload, and the compact token (decoded first, compact last, for pasting into a follow-up tool). The same token on many pages stays one recommendation; a different jku URL is a different row.
  3. Runs proven checks without extra HTTP (for example missing exp, symmetric alg advisories, JWT over cleartext HTTP, sensitive claims).
  4. When the sighting location allows safe replay, queues active probes (unverified signature acceptance, alg:none, embedded JWK confusion) subject to scope guards.

A response body is scanned for one token per algorithm, capped at 5. Position and rotating token values are not used as identity.

JWT tokens detected while this module is enabled are not also reported as secret-detection findings. JWT signing keys in responses still go through secret detection.

A Headless Browser crawl keeps Authorization and Cookie request headers so a later Nikto scan on the same host can still see tokens the browser sent.

Follow-up tooling

The jwt manual-review recommendation points operators at hands-on tools (for example jwt_tool) for claim tampering and algorithm confusion tests beyond what the platform probes automatically.

Next steps ​

  • Scans — launch, lists, scan detail (including Speed limit), pause/cancel
  • HTTP/3 scanning — QUIC opt-in and proxy bypass
  • Settings — Scan Defaults, enforced proxy / headers / throttle
  • Web Crawler — engine choice and crawl-only fields

Proprietary software. Licensed for use under the End User License Agreement.