Blog · Recon
How to monitor bug bounty scope for new subdomains (without babysitting a VPS)
New subdomains are the highest-value events in a bug bounty program's lifecycle: freshly provisioned, lightly tested, and briefly unclaimed. The hunter who catches them first wins. Here is how to monitor for them continuously — the do-it-yourself way, why it breaks, and the managed alternative.
Why new subdomains are worth monitoring for
A subdomain that appeared yesterday has been seen by fewer eyes than one that has existed for two years. It is more likely to be misconfigured, running a pre-production build, missing a WAF rule, or pointing at a dangling resource ripe for takeover. Programs add these constantly — new environments, new services, new acquisitions. Continuous subdomain monitoring is simply making sure you are the one who notices, on the day it happens rather than the month after.
The DIY approach: a subfinder + cron pipeline
The classic self-hosted setup looks like this:
- Enumerate subdomains on a schedule with
subfinder(plusamass,assetfinder, and passive sources for coverage). - Resolve and probe them with
dnsxandhttpxto find what's actually live. - Store each run, diff it against the previous run to isolate what's new, and dedupe.
- Pipe the new-subdomain diff to a Telegram or Discord webhook so you get pinged.
- Wrap the whole thing in a
cronjob on a VPS so it runs daily.
This genuinely works, and if you have the time and enjoy running infrastructure, it is a great setup. The value is real and the tooling is free.
Why the cron pipeline quietly fails
The trouble with a self-hosted monitoring stack is that its failure mode is silence. It doesn't crash loudly; it just stops surfacing new assets, and you don't notice until you happen to check:
- A passive source rate-limits or changes its API and one enumeration path goes dark.
- The VPS disk fills with historical scan output and writes start failing.
- A tool update changes output format and your diff script silently emits nothing.
- The cron job dies after a reboot and nobody restarts it.
Every one of these means missed windows on fresh scope — the exact thing you built the pipeline to catch. The infrastructure meant to save time starts costing it, and because it fails quietly, you pay the cost without knowing.
The managed alternative
The other option is to not run the infrastructure at all. Instead of maintaining a cron stack, you define the targets that match your bounty scope, pick a sweep cadence, and let a managed platform handle enumeration, resolution, probing, diffing, and alerting. New subdomains land in a diff feed and hit you over Telegram and email the moment they appear — no VPS, no cron, no dedupe scripts, and nothing to silently break.
The trade-off is a subscription instead of free tooling, in exchange for your time back plus built-in diffing, alerting, and per-finding attribution. We wrote an honest side-by-side of exactly this in ASMHunter vs self-hosted recon — including when the DIY stack is still the right call.
A practical checklist either way
- Tie monitoring to real scope. Monitor the domains actually in a program's scope so you stay inside authorized bounds.
- Sweep daily, at least. Weekly is a floor; serious public programs ship assets faster than that.
- Diff, don't re-read. You want the delta — the new subdomains — not a fresh full list every run.
- Alert out-of-band. Coverage should not depend on you remembering to log in and check.
- Keep attribution. Record which sweep and date surfaced each asset, so when a report pays you know what earned it.
ASMHunter monitors your bug bounty scope for new subdomains (and ports, endpoints, and findings) on managed infrastructure, with Telegram and email alerts and attribution per finding. Start free (no card), or read the guide to continuous attack surface monitoring.