ToolkitReconnaissance

Practical documentation · Authorized use only

DIRB

DIRB is a legacy-style web content scanner that remains useful for small, authorized baseline checks. Keep its runs low-impact, use locally approved wordlists, and validate any discovered resource through normal application review.

WebBruteforceCLI

Start safely and get useful results

Best for

  • • Small local content inventories
  • • Legacy assessment workflows

Not for

  • • Large-scale scanning
  • • Authenticated brute force

Before you run anything

  • • Document the authorized target, time window, success criteria, data-handling rules, and a named stop contact before you begin.
  • • Confirm the installed version with the tool’s version or help command, then compare its documented behavior with the linked upstream project before relying on any option.

Practical workflows

Beginner

Scan a local training server

Scenario: Check a disposable server for expected static paths.

dirb http://localhost:8080 ./approved-small.txt

Run against a local target with a reviewed small wordlist.

Expected use: Expect status-coded candidates; verify redirects and custom errors manually.

Intermediate

Record a bounded run

Scenario: Preserve evidence for a staging change review.

dirb https://staging.example.invalid ./approved-small.txt -o dirb-results.txt

Write output to an evidence file and retain the input wordlist checksum separately.

Expected use: Use the output as an inventory input, not a finding list.

Interpret results like an analyst

  • • A 200 response can still be a generic error body, so inspect content and length.
  • • A denied resource may be correctly protected; do not report it as exposure without an access-control test.

Common mistakes and operating tips

Avoid

  • • Running bundled lists without measuring request impact.
  • • Ignoring virtual hosts and base paths when interpreting a negative result.

Operational discipline

  • • Treat command output as evidence, not a conclusion: retain the command, version, scope, timestamp, and a redacted result in the engagement record.
  • • Start with the smallest safe scope, validate expected behavior in a lab or pilot, then expand only when the authorization and monitoring plan support it.

Verify against the current upstream

Tool behavior and release syntax can change. Treat this guide as practical operating context, then verify version-specific details against the upstream project before an assessment.

Open authoritative upstream documentation