Scan Types

Compare AYAsec scan types for TLS, HTTP, exposed ports, DNS posture, credibility signals, and asset discovery.

AYAsec runs six scan types against a target. Five of them (TLS, HTTP, Ports, DNS, Credibility) feed into the weighted Overall score; Discovery maps the surrounding attack surface and doesn't.

TLS

Certificate chain validation, supported protocol versions (flagging SSLv2/SSLv3/TLS 1.0/1.1 as legacy), cipher suite strength, forward secrecy, HSTS, and known protocol-level vulnerabilities. The report includes the full certificate chain, cipher suite table, and browser/client compatibility matrix.

By default AYAsec checks the first resolved address. Advanced Scan can enable Scan all resolved IPs to test every IPv4 and IPv6 address returned for the hostname.

HTTP

Security headers, technology fingerprinting, and CVE matching against detected software versions. Runs in one of three profiles:

  • Passive - fingerprinting and header analysis only, no attack traffic sent
  • Active - adds live exploit checks for matched vulnerabilities
  • Extended - a deeper crawl and broader active assessment

Findings include detected technologies (server, frameworks, libraries, CDN/WAF/proxy), external services, and scan-level insights like status code and content-type mix.

All profiles use a headless browser crawl for JavaScript-rendered content. Active and Extended scans can use a custom ZAP scan policy; HTTP scans can also use saved session-based form authentication, a static request header, or a custom IP and port.

Ports

Sweeps for open ports and identifies the service and version listening on each, then matches detected versions against known CVEs. Expected, non-actionable exposures (like HTTPS on 443) are listed in the raw port table but don't generate a finding on their own - only genuinely risky exposures do.

By default only the first resolved IP is scanned; the Scan all resolved IPs toggle scans every address the domain resolves to, across both IPv4 and IPv6.

If a workspace has other domains, a Ports scan also checks whether any of them resolve to the same IP address it just scanned - either the single address, or one of every address if Scan all resolved IPs is on. A domain that shares an IP with the one actually scanned reuses that result instead of being scanned again, and its report shows a shares results with another domain badge linking to the scan it inherited from.

DNS

Record enumeration (A/AAAA/MX/NS/TXT/CNAME/SOA), DNSSEC status including NSEC/NSEC3 walkability, nameserver redundancy, zone transfer (AXFR) exposure, wildcard records, open resolver checks, subdomain takeover risk, dangling DNS records, and email authentication - SPF, DMARC, MTA-STS policy content, and TLS-RPT. Email-auth findings scale with whether the domain actually sends mail: a domain with no MX record isn't penalized for missing DMARC.

Credibility

Domain and IP reputation: DNSBL blacklist status, domain age, AbuseIPDB confidence score, Google Web Risk, and AlienVault OTX threat-intelligence matches.

Discovery

Subdomain enumeration and related-domain mapping, with TCP liveness, HTTP status codes, redirects, WAF hints, authentication hints, and optional ASN/geo enrichment for resolved IPs. Deeper technology fingerprinting and CVE matching belong to the dedicated HTTP/Ports scans, not the Discovery probe itself. Open it from Assets Discovery and choose a scope (an asset, asset group, or a typed apex domain), then review the combined sources before starting. This is how you find the subdomains and shadow IT you didn't know about - it's exploratory by nature, so it feeds a per-host security score for context rather than the target's weighted Overall grade.

Seeding Discovery with domains you already know about

Discovery's own enumeration (crt.sh, DNSDumpster) is passive and won't catch everything - internal hostnames, wildcard records, or anything else with no public certificate. On top of that passive sweep, you can seed a scan with domains you already know about, two ways:

  • Manual import - upload a domain/zone-file list when starting a scan. Supported formats: plain text, BIND zone file, AXFR, CSV, and JSON. Hosts under the target's own domain are added as subdomains; any other domain in the list is dropped unless your organization has separately verified ownership of it (see Verifying domain ownership below), in which case it's added as a related domain instead. Capped at 1,000 hosts per scan.
  • Connected DNS provider - connect a hosting/DNS provider account once, and every subsequent Discovery scan for that workspace can pull the account's zones and DNS records. Hosts under the target's own domain are added as subdomains; other domains in the same account are added as related domains. The provider catalog currently contains 248 providers ; the UI shows which providers support zone collection and the exact credential fields for the selected one.

Either way, every host in the report carries a Source column: hosts added this way show "User Uploaded" (with the filename) or the provider's name, while everything found by Discovery's own passive sweep just shows "Discovery" - so you always know which results came from data you supplied versus what Discovery found on its own, without the report disclosing which specific techniques the passive sweep uses.

Connecting a provider

Open New Discovery Scan , pick a provider from the DNS provider dropdown, and - if the workspace isn't connected to it yet - a credential form appears right there, no detour through Settings required. AYAsec verifies the credentials before storing them (encrypted at rest), and reuses the connection automatically for every later Discovery scan in that workspace until you disconnect it. Disconnecting stops future scans from fetching new hosts, but doesn't remove hosts already found in past scan results.

What each provider needs:

  • Cloudflare - a scoped API Token (My Profile → API Tokens → Create Token → Custom Token) with Zone → Zone → Read and Zone → DNS → Read , scoped to All zones or the ones you want included.
  • AWS Route53 - an IAM Access Key ID + Secret Access Key with a least-privilege policy allowing route53:ListHostedZones and route53:ListResourceRecordSets (the built-in AmazonRoute53ReadOnlyAccess managed policy covers this).
  • Azure DNS - an App Registration's Tenant ID, Client (App) ID and Client Secret, plus your Subscription ID, with the built-in Reader role assigned at the subscription scope (Azure has no narrower built-in DNS-only read role).
  • Google Cloud DNS - a service-account JSON key (paste the whole file) plus the Project ID, with the roles/dns.reader IAM role granted to that service account.
  • DigitalOcean - a Personal Access Token scoped to read-only Domain access.
  • Hetzner - a Hetzner Cloud project API token created with Read permission (Cloud Console → Security → API Tokens). Hetzner retired its old standalone DNS API in 2026 - DNS now lives in the same Cloud API as servers.
  • GoDaddy - an API Key + Secret pair from the GoDaddy Developer portal. GoDaddy has no read-only scope - the key grants full account access, so treat it with the same care as a password.
  • Contabo - an OAuth2 Client ID + Client Secret (Customer Panel → API) together with your account email and password.