Vexta's Per-Host Recon Depth on Every Asset Row

Vexta is VITI Security's agentless, AI-augmented vulnerability scanner and pentest platform, and its per-host recon depth means every row on the Assets tab already carries the context a hunter would otherwise open five tabs to gather. Each asset row surfaces IP addresses, CNAME and PTR records, ASN, organization and country, open ports with a parsed banner, service and product or version string such as OpenSSH 8.9p1 or nginx/1.18.0, an OS guess with its supporting evidence, a TLS certificate summary, and a screenshot when one was captured.

What recon runs before an asset row gets built?

Several recon passes feed into a single asset row, all running natively rather than shelling out to external tooling. Per-host screenshots are captured (capped at 200 hosts per scan). Email harvesting pulls from crawled-page text, WHOIS registrant data, search-engine dorks and the Hunter.io API, and addresses are lowercased on write so case-different variants of the same address aggregate instead of showing up as duplicates. Search-engine dorking runs roughly 30 curated dorks through a fallback chain, trying Google's Custom Search API first, then Bing's API, then falling back to scraping Google, then Bing, then DuckDuckGo if the earlier sources are unavailable. Pacing adjusts to match: paid API calls run without a delay, while the keyless scrape steps self-pace with a 0.5 to 2 second gap between requests so the dorking pass does not hammer a search engine's scrape-facing pages.

Archive-URL aggregation pulls from Wayback, CommonCrawl's top three indices, AlienVault OTX and URLScan in parallel, each with its own timeout so one slow source does not hold up the rest, which matters because these archive sources surface old, forgotten endpoints and parameters that an active crawl of the live site would never find on its own. Directory and content-discovery fuzzing walks an embedded path list with extension permutation matched to the detected stack,.php for WordPress,.aspx for IIS,.jsp for Tomcat, at a configurable depth from 0 to 3, breadth-first. A sensitive-file and backup probe checks roughly 150 embedded paths, with path-shape signature checks built in specifically to reject the false positives you get from a single-page app that returns 200 for every path. Every crawled URL also gets bucketed by injection class, so XSS, SQLi and SSRF candidates, among others, land in their own per-class lists instead of one undifferentiated pile.

What actually shows up on the asset row itself?

The identity fields come first: IP, any additional IPs, CNAME, PTR, ASN, organization and country, so a hunter can tell at a glance what they are looking at and who owns it. Open ports carry a parsed banner plus the service and product or version Vexta extracted from it, not just a bare port number, examples given in the product's own documentation include OpenSSH 8.9p1, vsFTPd 3.0.3 and nginx/1.18.0. A screenshot path is attached when one was captured for that host, so the visual and the technical detail sit on the same row instead of needing to be cross-referenced by hand.

How confident is Vexta's OS guess, and where does the evidence come from?

Every OS guess comes with a confidence level and the evidence behind it, not just a label. A passive layer runs always-on, drawing on banner and negotiation data: SSH version strings, SMB OS-version negotiation, RDP NTLM challenges, FTP banners, and the HTTP Server header. On top of that, an opt-in active fingerprinting step sends an ICMP TTL probe to narrow the guess further; check the pricing page for which tier includes it. That active step skips silently when the binary does not have the CAP_NET_RAW capability it needs to send a raw ICMP probe, so a scan running without that permission simply falls back to the passive evidence rather than failing outright.

That distinction, passive always-on versus active opt-in, matters for a hunter thinking about footprint. Passive OS fingerprinting reads data the target is already sending as part of normal protocol negotiation, so it adds nothing extra to the wire. The active ICMP step is a deliberate, additional probe, which is exactly why it is opt-in rather than automatic.

What does the TLS summary on an asset row cover?

Every asset row with a TLS-enabled service gets a certificate summary: subject, issuer, NotBefore and NotAfter dates, subject alternative names, and flags for whether the certificate is expired or self-signed. That is enough to spot an expiring or self-signed cert without opening a separate tool, and it sits right next to the port, banner and OS data for the same host, so a hunter reviewing a large asset list can catch a certificate problem in the same pass as everything else instead of running a dedicated TLS sweep afterward.

What does this save a hunter during triage?

The alternative to this is familiar to anyone who has run recon by hand: a terminal tab for the port scan, a browser tab for a manual screenshot, a separate WHOIS lookup, a certificate checker pasted into another tab, and a notes file trying to hold it all together per host. Multiply that by dozens or hundreds of assets in a scope and the overhead stops being a minor annoyance and starts eating hours that should go toward actually testing something.

Putting identity, ports, banners, OS evidence, TLS data and a screenshot on one row does not replace judgment, a hunter still decides what is worth chasing, but it removes the busywork of assembling the picture before that judgment call can even happen. On a scope with real breadth, that is the difference between spending the first day of an engagement building a spreadsheet and spending it actually looking for something.

Key takeaways