Scan engines · Service fingerprinting

scout

Works out what a live service is running, down to product and version, then derives the CVE leads and the WAF profile the scanner needs.

Daemon port: 4444
Licence: Apache-2.0
Install: crossfyre extension install scout

Contents

What it detects Standalone usage Probing depth Output On the platform

scout takes a live web service and works out what it is running. It fetches the target, reads the signals a server gives away (headers, cookies, the HTML, the generator meta tag, the favicon) and matches them against a curated signature set to identify the web server, language, framework, CMS and JavaScript libraries in use, with versions wherever the target exposes them. From each product and version it derives version-based CVE leads, detects the WAF, CDN or load balancer in front of the service, and computes a Shodan-compatible favicon hash for pivoting. It is the enrichment stage between discovery and vulnerability scanning.

What it detects

Technologies and versions: web servers (Nginx, Apache, IIS, Tomcat and more), languages and runtimes (PHP, Java, Python, Node.js), frameworks (ASP.NET, Laravel, Django, Rails, Spring, Express), CMSes (WordPress, Drupal, Joomla, Magento) and JS libraries (React, Vue, Angular, Next.js, jQuery). A detected technology pulls in the ones it implies: WordPress implies PHP and MySQL, Tomcat implies Java.
CPEs: each detection emits a CPE identifier carrying the detected version, the join key that CVE matching pivots on.
WAF / CDN / load balancer: passively identifies the edge and protection vendor in front of a service (Cloudflare, Akamai, CloudFront, Fastly, Sucuri, Imperva, F5 BIG-IP, ModSecurity) from its tells.
Favicon hash: an mmh3 hash compatible with Shodan's http.favicon.hash, plus MD5, for correlating hosts across your surface.
CVE leads: for each detected product and version, scout matches a version-ranged CVE ruleset and flags the versions that fall in a vulnerable range.

Warning

CVE leads are version-inferred, not confirmed. They flag that a version sits in a vulnerable range, but a backported patch can make that a false positive. They are leads for cortex to confirm, not final findings.

The ruleset ships with a starter set and can be extended at runtime by pointing SCOUT_CVE_FILE at your own JSON rules, with no rebuild.

Standalone usage

scout --daemon &                       # start the engine (port 4444)

# fingerprint a single service
scout fingerprint https://example.com
scout fingerprint example.com:8443

# full control: timeout, redirects, favicon, probing depth
scout exec '{"operation":"fingerprint","target":"https://example.com","depth_tier":2,"favicon":true}'

Probing depth

The depth_tier parameter controls how much active probing scout does against a target. Lower tiers are quieter against sensitive targets.

Tier	What it does
`0`	Passive: only the signals in the landing response.
`1`	Quiet: adds the favicon fetch.
`2`	Standard. The default.
`3`	Aggressive.

A per-request timeout_ms and a follow_redirects toggle round out the knobs, and an auth object lets scout fingerprint the authenticated surface.

Output

scout emits four kinds of finding: a technology record per detection (name, category, version, CPE, confidence and the evidence that matched), a service summary (status, title, server, WAF/CDN, favicon and the tech list), a vulnerability record per CVE lead, and an environment record that tells the vulnerability scanner how to behave: whether a WAF is present, which status codes that WAF blocks with, and a recommended pace.

On the platform

scout runs after discovery: it takes the live web services that pulse and mach surfaced, enriches each one, and writes the results into the shared asset graph. Its environment record is what lets cortex pace itself sensibly against a WAF-fronted target, and its CPEs tie a detected version to the checks that matter.