Ownership is enforced twice per scan
A scan request is rejected up front unless the host sits under a verified domain, and the check is repeated in the worker that actually runs the scan, because a scan can be queued and execute minutes later. The same gate applies to scans started from the app, the MCP server and the REST API: no interface can scan anything the account could not scan already.
DNS and file proofs are re-checked nightly (see Getting started). A domain whose proof disappears is demoted and stops being scanned.
What we send to your hosts
| Activity | What it looks like on your side |
|---|---|
| HTTP(S) GET requests | Ordinary page loads, the kind a browser makes: the HTTPS and plain-HTTP homepage and up to 10 same-host links (500 KB per page, 10 seconds per request), plus up to 6 requests for the root page of open admin web ports. Response headers, cookies and page markup are read. Redirects are followed only on the same host. |
| TLS handshakes | A normal handshake on 443 and any extra ports you list, including STARTTLS for mail ports. Separate handshakes check whether TLS 1.0 and 1.1 are still accepted. |
| TCP connect | A connection opened and closed on each of 123 ports that matter, 25 at a time with a 3-second timeout. On ports that send a greeting of their own (SSH, SMTP, FTP and similar), we read that greeting and send nothing. Only web ports are tried when a host sits entirely behind a shared CDN. |
| DNS lookups | Standard queries through public resolvers. |
What we never do
- No exploit attempts, payloads, fuzzing or injection strings.
- No login attempts, credential stuffing or brute force.
- No load or stress testing. Requests are few and spaced out.
- No form submissions. Forms are read from the page markup only.
- No packets of any kind to a host that is not under a verified domain. Lookalike domains, candidate related domains and third-party dependencies are observed only through public DNS and public datasets (certificate transparency, web archives), never connected to.
Vulnerability findings are therefore matches, not exploit confirmations: they say that the software and version a host announces is affected by a known CVE. See Vulnerability matching.
What we read from public sources
Some checks never touch your hosts at all: certificate transparency logs, RDAP registry records, public DNS and DNSSEC validation through public resolvers, web archive and crawl indexes, cloud provider IP range files and public abuse feeds. The full list, with licences, is on Data sources & licences.
How the scanner identifies itself
Every HTTP request carries this User-Agent:
AFS-Scanner/1.0 (+https://attacksurfacescan.com/scanner)The URL in it leads to a page for site owners explaining who we are and how to report misuse.
Scans run on AWS Lambda in the US East (N. Virginia) region and come from AWS us-east-1 address space. There is no fixed list of source IPs, so identify the scanner by its User-Agent.
Allowlisting and WAFs
If a WAF or rate limiter blocks the scanner, results for that host will be incomplete rather than wrong: blocked checks produce no finding instead of a false one. To see the same surface an attacker sees, do not allowlist us; to see the surface behind your WAF, allowlist the User-Agent above (there is no fixed IP list to allowlist).
When a check cannot complete
Every module is independent and time-boxed. A host that times out, a registry that rate-limits or a public feed that is down produces no finding for that check, never a failed scan and never a false positive. Persistent problems surface as their own findings (for example an extra TLS port that stops answering, or a monitored endpoint unreachable for 18 hours).