Targeted Subscans in Vexta: Rescan One Endpoint Without Redoing the Whole Job

A targeted subscan is a way to rescan just one asset with a single module, instead of re-running an entire scan to check one thing. Vexta is VITI Security's agentless, AI-augmented vulnerability scanner and pentest platform, and its subscan feature lets you point one of seven modules, like a port scan or a directory bruteforce, at a specific subdomain, endpoint or IP without touching the rest of the target.

What modules can a subscan run?

Seven modules are available: port_scan for top-port scanning, vuln_scan for vulnerability detection, screenshot for capturing a visual, js_analysis for JavaScript analysis, dir_brute for directory bruteforcing, param_fuzzer for parameter discovery, and tech_detect for technology fingerprinting. Each one can be run on its own against a specific target type: subdomain, endpoint or IP.

That granularity is the whole point. A full scan runs all of this together across an entire target. A subscan lets you ask a narrower question about one asset, like whether a single subdomain now exposes new open ports, without waiting for a full scan cycle to answer it.

When does a hunter reach for a subscan instead of a full rescan?

Say a full scan already ran against a target and flagged forty subdomains. A week later, one of those subdomains gets redeployed with a new build. Running a full scan again to check that one subdomain wastes time and generates noise against assets that have not changed. A dir_brute or tech_detect subscan against just that subdomain answers the specific question: did the new deployment expose a new directory, or change the tech stack fingerprint.

The same logic applies mid-engagement. If you spot something interesting on one endpoint during manual testing and want a fresh param_fuzzer pass against it right now, a subscan gets you that answer in minutes rather than re-queuing the whole target and waiting for everything else to finish first.

It also helps on a target big enough that a full scan takes hours. If a client reports that one specific service just came back online after maintenance, a port_scan subscan against that one IP confirms it in the time a full rescan would still be crawling through unrelated subdomains.

How does a subscan differ from the built-in scan types?

Vexta's pre-scan options already include a Scan Type field with full, recon, vuln and deep modes, which control what an entire scan against a target does. A subscan operates one level below that: instead of choosing what an entire scan run covers, you are choosing one module and one asset. Think of scan type as scoping a job, and a subscan as scoping a single follow-up question about something that job already touched.

This also means subscans are cheap to run repeatedly. A screenshot subscan against a handful of endpoints you are keeping an eye on, run every so often, is a lighter way to notice visual changes than re-running a deep scan against the whole target just to catch a redesign or a defacement.

What does each module actually look for?

port_scan sweeps the top ports on an IP or resolved subdomain, which is the fastest way to confirm whether a service that was closed last time is now listening. vuln_scan runs Vexta's detection logic against a single asset, useful when you want a fresh verdict on one host without paying for a scan of everything around it. tech_detect re-fingerprints the technology stack behind an endpoint, which matters the moment a target migrates a framework or CMS version, since that shift can open or close whole categories of applicable checks.

js_analysis re-parses a target's JavaScript for endpoint references and hardcoded values, which is worth rerunning on its own whenever a front-end build changes, since a new bundle can quietly expose a new API route that was not there during the original scan. dir_brute and param_fuzzer both do focused enumeration, directory paths and request parameters respectively, and both are naturally suited to a single-asset subscan because bruteforcing an entire target's worth of assets on every check would be slow and noisy for no added benefit. screenshot simply recaptures what a page looks like right now, cheap enough to run on a schedule against a handful of endpoints you are watching.

Staying inside scope when you run a subscan

A subscan is still an active probe against a live asset, even though it touches less surface than a full scan. That means the same authorization rule applies: only run one against a subdomain, endpoint or IP that is in scope under a program's rules or a signed engagement. Because a subscan is fast and cheap to trigger, it is tempting to fire one off at something adjacent to the scope just to check, and that is exactly the moment worth pausing on. If an asset is not explicitly in scope, a subscan against it is not authorized just because it is quick.

Key takeaways