ToolkitReconnaissance

Practical documentation · Authorized use only

Findomain

Findomain aggregates certificate-transparency and OSINT sources for subdomain discovery. Use it to seed an authorized inventory and compare source results over time, while recognizing that CT data often includes expired, internal, or third-party names.

OSINTReconSubdomainsRustASM

Start safely and get useful results

Best for

  • • Passive domain inventory
  • • Certificate-transparency review

Not for

  • • Automated host probing
  • • Ownership conclusions from names alone

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

Collect candidate subdomains

Scenario: A domain owner authorizes passive discovery for one root domain.

findomain -t example.com -q

Query passive sources for the approved domain and emit concise candidate output.

Expected use: Expect historical and duplicate entries that require validation.

Intermediate

Save a timestamped inventory

Scenario: Compare exposure candidates between quarterly reviews.

findomain -t example.com -q -u findomain-$(date +%F).txt

Store an evidence file with its run date for controlled comparison.

Expected use: New names are candidates for asset-owner review, not immediate security findings.

Interpret results like an analyst

  • • Certificate issuance indicates a name existed in a certificate context; it does not prove a currently reachable service.
  • • Classify results as owned, delegated, historical, unknown, or out-of-scope before any further action.

Common mistakes and operating tips

Avoid

  • • Treating CT visibility as authorization to test a host.
  • • Missing wildcard or SAN context when interpreting names.

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