Vexta's Per-Host Screenshot Snapshot Bundle

Vexta's per-host snapshot bundle answers what does this host actually look like by pulling everything Vexta learned about it into one document behind a single button. Vexta is VITI Security's agentless, AI-augmented vulnerability scanner and pentest platform, and on a scan with dozens or hundreds of live hosts, the snapshot bundle is what turns a wall of separate recon fields into something a hunter can actually skim, host by host, without opening five different tabs per asset.

What goes into a single host snapshot?

Each snapshot composes a screenshot of the host alongside its identity data (IP address, CNAME, PTR record, ASN, owning organization, and country), an OS guess with its confidence and supporting evidence, the full list of open ports with parsed banners, services and product versions (things like OpenSSH 8.9p1 or nginx/1.18.0), a TLS certificate summary, the technology fingerprint, any discovered email addresses tied to the host, and the results of any NSE scripts that ran against it (NSE, the Nmap Scripting Engine, runs small probe scripts against open ports to pull extra detail beyond a basic port scan). All of it lands in one document per host, generated on request rather than sitting scattered across separate recon tabs.

The OS guess behind that document comes from two layers. A passive layer is always on and reads banner strings that services hand over voluntarily: SSH version strings, SMB's OS-version negotiation, RDP's NTLM challenge, FTP banners, and the HTTP Server header. An active layer, opt-in and available on Pro and above, sends an ICMP TTL probe for a TCP/IP fingerprint; it skips itself silently if the running binary doesn't have the CAP_NET_RAW permission needed to send raw packets, so it never blocks the rest of the scan when that permission isn't available.

How do you pull up a snapshot?

Every host row on the Assets tab carries a Snapshot button. Clicking it calls a single endpoint that assembles the full document, screenshot through NSE results, in one response, so there's no separate round trip per data type. The result is a per-host reference you can open while triaging a finding on that same host, without losing your place in the findings list to go dig up the port scan or the TLS details separately.

That matters most on recon-heavy engagements where the number of live hosts is large enough that remembering which host had the self-signed cert, or which one was running an outdated FTP banner, becomes its own bookkeeping problem. The snapshot bundle keeps that bookkeeping inside Vexta instead of a separate spreadsheet.

Why a screenshot belongs next to the port data

A screenshot answers a question port data alone can't: what is actually rendering on this host right now. A host might show an open port 443 with a plausible-looking TLS cert and still be serving a default landing page, an error page, or a login portal that's clearly out of scope for the engagement. Seeing the screenshot next to the OS guess, the open ports and the TLS summary lets you rule hosts in or out for deeper testing faster than reading the raw data alone, especially across a target list too large to manually browse to every host in a real browser.

Pairing the visual with the TLS certificate summary, subject, issuer, validity window, SANs, and flags for expired or self-signed certs, also surfaces low-effort findings on its own. A host serving a self-signed cert on what the screenshot shows is a production login page is worth a second look well before you get to running detectors against it.

Why the discovered emails and technology fingerprint belong in the same document

The snapshot doesn't stop at what's visible on the page. It also includes any email addresses discovered in connection with the host and the technology fingerprint identified during recon, alongside the port, service and OS data. Having emails sit in the same document as the OS guess and open ports matters for a specific reason: those emails are often the fastest way to identify who owns or operates a given host when a finding needs to be reported or a scope question comes up, and having them attached to the same asset record as the technical detail saves a separate lookup.

The technology fingerprint in that same bundle is what lets you connect a host to a broader pattern across a target. If the same content management system or framework version shows up on the fingerprint field across several hosts in one snapshot after another, that's a much faster way to spot a shared weakness across a target's infrastructure than noticing it independently on each host's own recon pass.

Fitting the snapshot into a triage workflow

In practice, the snapshot button gets used at two points in a scan. Early on, during recon review, it's a fast way to sanity-check which hosts look like they're actually worth deeper testing before committing detector time to them, since a screenshot next to the OS guess and open ports gives a clearer sense of what a host is for than any single field alone. Later, during finding triage, pulling up the snapshot for the host behind a specific finding gives you the full context, ports, banners, cert, tech fingerprint, in one place instead of re-running separate lookups to remember what else was running on that box.

That second use case is the more valuable one on a long engagement. By the time you're a few hundred findings into a large scan, it's easy to lose track of which host had which service versions. Rather than trusting memory or scrolling back through an earlier recon tab, the Snapshot button on that host's row in the Assets tab regenerates the same composed document on demand, so the reference is always current rather than a note taken hours earlier that might already be stale if the host changed in the meantime.

Key takeaways