I already scanned for open ports. Do I still need this?

Yes, if you want the web-tail entry: live HTTP URLs with title, status, TLS, and CDN. Open-ports tells you a TCP port is open. It does not speak HTTP. The two tails share a host list and then split. Do not feed this into network fingerprinting, and do not feed open-ports into web fingerprinting.

Where do the extra hostnames come from?

From the HTTP response: TLS SAN and CN, CSP directives, and redirect targets. That is a side output, not hostname enumeration. For names in HTML and JavaScript across a crawl, use the hostname-crawl module after this.

Which ports does it probe?

The most likely HTTP ports. For hosts behind a cloud WAF or CDN, only 80 and 443. There is no port override on this face. For arbitrary TCP, use the open-ports module.

Can I feed harvested names back in?

Yes. Dedupe and re-scope, then feed them as `hosts`. `potential-hostnames` are outside strict scope; re-scope before you scan them. One pass does not finish the surface.

How do I probe a list of hostnames or IPs for live web servers?

Feed a FILE of hosts to this module. It probes the common HTTP ports on every entry, drops the names that don't answer, and returns live web server URLs plus a JSONL details bundle per live server. That bundle is what the next web-tail step nests on.

Can I probe a CIDR range for web servers?

Yes. The `hosts` input accepts hostnames, IP addresses, and CIDR ranges, one per line. CIDR is a first-class input; every IP in the range is probed on the common HTTP ports.

What metadata comes back for each live web server?

A JSONL record per live server with title, status, redirect, length, favicon, server header, CDN, and full TLS. The module keeps paths and queries from the input when they are present. That bundle is the typed face the next step nests on.

What runs after a web server probe in a recon pipeline?

Fingerprint Web Technologies consumes the `web-servers` output to name CMS, CDN, and WAF. Path crawling, technology-specific checks, and the scan report sit after fingerprint, not on raw hosts. Harvested hostnames from TLS SAN, CSP, and redirects can be deduped, re-scoped, and fed back as `hosts` for another pass.

2026-08-13

Attack Surface Management

Probe for Web Servers

Probe hostnames, IPs, or CIDR on common HTTP ports and keep the live web servers with title, redirect, status, server header, CDN, and TLS. The web-tail entry for recon pipelines.

What Probe for Web Servers does

A raw list of hostnames, IPs, or CIDR ranges is mostly dead weight. This module probes the common HTTP ports on every entry, drops the names that don't answer, and returns a typed bundle per live web server (title, redirect, status, server header, CDN, and full TLS) ready to nest into the next step of a recon or attack-surface pipeline. One pass also harvests new hostnames from TLS SAN, CSP, and redirect targets, so the output feeds the next enumeration.

You have a list of hostnames, IPs, or CIDR ranges. Most of it is dead. Probe the most likely HTTP ports on every entry, keep the ones that answer, and write a details bundle per live server: title, status, TLS, CDN. Extra hostnames in TLS SAN, CSP, and redirects are a side output, not hostname enumeration. This is the web-tail entry: hosts -> probe-web -> web FP -> tech-specific. A 200 is a live HTTP answer, not a finding. A harvested hostname is a hint, not a confirmed in-scope name.

Where it fits in the pipeline

Illustrative excerpt. Each node is a Trickest module.

Pipeline guidance

Do not cross-wire into the network tail:

Upstream: the five hostname enumerators, or Enumerate DNS Records. A static host / IP / CIDR list works too.
Downstream: Fingerprint Web Technologies consumes web-servers. Path crawling, technology-specific checks, and the scan report sit after fingerprint, not on raw hosts.
Parallel: Scan for Open Ports on the same hosts input. That is the network-tail entry. This is the web-tail entry. They share upstream. They do not share output.

Dedupe and re-scope harvested hostnames, then feed them back as hosts. That loop is optional. It is not hostname enumeration.

When to use this

Nest this after you have a host list from DNS or OSINT, and before any web fingerprinting, path discovery, or technology-specific scan. If you still need unpublished names, enumerate first. If you need CMS, CDN, or WAF names, fingerprint after this, on the live URL list this emits.

Inputs and outputs

Required: hosts (FILE). Hostnames, IP addresses, or IP ranges, one per line.
Optional: header (STRING). Header(s) to include in HTTP requests.
header-file (FILE). File of header(s) to include in HTTP requests.
Outputs: web-servers: live web server URLs. This is what the next web-tail step nests on.
web-server-details: JSONL per live server. Details include title, status, TLS, and CDN, plus redirects, length, favicon, and server header. The module keeps paths and queries from the input when they are present.
Hostname harvest (side output, not an enumerator): subdomains / subdomain-details, potential-hostnames / potential-hostname-details, subdomain-wildcards / subdomain-wildcard-details, and potential-hostname-wildcards / potential-hostname-wildcard-details. Names come from TLS SAN and CN, CSP, and redirect targets. potential-* rows are outside strict scope.

Data

The tables this module produces. Sample rows are illustrative.

web-servers1 column · 3 sample rows

Live web server URLs. This is what the next web-tail step nests on.

	urlurl
1	https://example.com
2	https://api.example.com
3	http://staging.example.com:8080

web-server-details16 columns · 3 sample rows

JSONL record per live server. The typed bundle the next step nests on.

	timestampdatetime	portint	urlurl	inputtext	schemetext	webservertext	methodtext	hosttext	pathtext	status_codeint	content_lengthint	titletext	cdnbool	cdn_nametext	tlsjson	headersjson
1	2026-08-13T20:14:03Z	443	https://example.com	example.com	https	nginx	GET	example.com	/	200	1280	Example	true	cloudflare	{3}	{3}
2	2026-08-13T20:14:04Z	443	https://blog.example.com	blog.example.com	https	nginx	GET	blog.example.com	/	301	0	Example Blog	true	cloudflare	{3}	{2}
3	2026-08-13T20:14:05Z	8080	http://staging.example.com:8080	staging.example.com:8080	http	apache	GET	staging.example.com	/	401	384	Unauthorized	false	NULL	NULL	{2}

subdomains4 columns · 3 sample rows

Hostnames discovered from the HTTP response (TLS SAN, CSP, redirects). Side output, not an enumerator.

	hostnametext	data_sourcetext	contexttext	linked_assettext
1	www.example.com	tls-san	certificate subjectAltName	example.com
2	assets.example.com	csp	Content-Security-Policy directive	example.com
3	redirect.example.com	redirect	301 Location header	example.com

How it differs from similar modules

Probe for Web Servers

Artifact class it owns

Live HTTP(S) URLs and a details bundle (title, status, TLS, CDN)

Upstream it needs

Hosts

Scan for Open Ports

Artifact class it owns

Open TCP ports

Upstream it needs

Hosts

Fingerprint Network Services

Artifact class it owns

Protocol, banner, product

Upstream it needs

port-details from open-ports

Fingerprint Web Technologies

Artifact class it owns

Technology taxonomy on live web URLs

Upstream it needs

web-servers from this module

Enumerate Hostnames via Crawling

Artifact class it owns

Hostnames pulled from a crawl

Upstream it needs

Live web-servers

questions