ToolkitReconnaissance

Practical documentation · Authorized use only

EyeWitness

EyeWitness turns an approved list of web endpoints into visual evidence and a reviewable report. It is valuable for attack-surface validation, exposed-admin-page review, and certificate or header triage without treating a screenshot as a vulnerability finding.

WebReconScreenshotPython

Start safely and get useful results

Best for

  • • Web inventory evidence
  • • Human review of exposed services

Not for

  • • Credential testing
  • • Authenticated application crawling

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

Capture a small approved URL list

Scenario: Review the public URLs in a controlled staging inventory.

python3 EyeWitness.py --web -f approved-urls.txt -d eyewitness-output

Read targets from a reviewed file and store the generated report in a dedicated evidence directory.

Expected use: Expect screenshots, headers, and a report; manually validate redirect and TLS anomalies.

Intermediate

Make evidence reproducible

Scenario: Compare the exposed staging surface before and after a release.

sha256sum approved-urls.txt > approved-urls.txt.sha256

Hash the input scope before capture so the report can be tied to a fixed target list.

Expected use: The output supports visual comparison; it does not establish authentication, authorization, or exploitability.

Interpret results like an analyst

  • • Use screenshots to prioritize human review, particularly unexpected login pages, default pages, and certificate warnings.
  • • Headers are context only; verify them with the service owner before reporting a security impact.

Common mistakes and operating tips

Avoid

  • • Feeding unreviewed Internet-wide target lists into the tool.
  • • Interpreting a failed screenshot as a host outage without checking redirects, DNS, or TLS.

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