Why does subzy read HTTP responses instead of CNAMEs alone?

A dangling CNAME does not always mean a claimable page. subzy requests each host and matches can-i-take-over-xyz fingerprints in the body, so you only triage hosts whose live response looks claimable. Use -hide_fails to drop clean hosts from the output.

How do I scan a large subdomain list with subzy?

Pass a file with -targets, raise -concurrency above the default 10 for a wide scope, and set -hide_fails so the output lists only takeover candidates. -timeout controls how long each request waits before subzy moves on.

Does subzy detect DNS zone or nameserver takeover?

No. subzy works on HTTP and HTTPS responses, so it finds service and CNAME takeovers, not dangling nameserver delegations or zone-level issues. For a dangling NS record you need a DNS-focused check; subzy covers the response-fingerprint class that can-i-take-over-xyz tracks.

How does subzy compare to tko-subs?

Both hunt takeover conditions. subzy matches live responses against can-i-take-over-xyz fingerprints and stays detection-focused. tko-subs uses a providers CSV and can optionally claim some dangling resources; use that when you need the claim path, not just detection.

How do I fix a subdomain takeover subzy reports?

Remove the dangling DNS record or reclaim the resource it points at. If the subdomain no longer needs to exist, delete the CNAME; if it does, re-create the target service under your account so the name resolves to something you control. Re-run subzy afterward to confirm the host no longer matches a takeover fingerprint.

Updated Jul 14, 2026

Vulnerabilities

Flag claimable dangling services on subdomains

Subdomain takeover checks driven by can-i-take-over-xyz response fingerprints.

Confirm takeovers across a discovered surface Hunt dangling cloud and SaaS records Keep takeover scans focused

overview

What subzy does

subzy reads a subdomain list and tests each host for a takeover condition. It requests the host, reads the response, and matches it against the fingerprint set from the can-i-take-over-xyz project. When a subdomain points at a deprovisioned cloud service that still answers with a claimable error page, subzy flags it as vulnerable.

The check is response-driven, so it avoids many false positives that come from CNAME inspection alone. Scan a single host with -target, a comma-separated set, or a file via -targets. Tune -concurrency, -timeout, and -https to match the scope. Set -hide_fails to keep output on hosts worth acting on.

Place it after subdomain enumeration: discovery produces candidate names, subzy confirms which resolve to claimable services, and findings land as FILE and FOLDER output. Pair with tko-subs when you also need optional claim actions.

source github.com/LukaSikic/subzy

use cases

Where subzy fits

Confirm takeovers across a discovered surface

Feed a full subdomain list into subzy so every host is tested against the live fingerprint set, surfacing only the names that point at claimable, dangling services.

Hunt dangling cloud and SaaS records

Catch subdomains that still CNAME to a deleted S3 bucket, GitHub Pages site, or Heroku app, the exact conditions an attacker uses to hijack a domain.

Keep takeover scans focused

Set -hide_fails to drop non-vulnerable hosts and raise -concurrency so a wide scope finishes quickly with output that only lists actionable findings.

Re-scan on a schedule to catch new exposure

Wire discovery plus subzy into a scheduled Trickest workflow so newly created subdomains are tested for takeover as they appear, without a manual pass.

reference

subzy inputs and flags

7 inputs

Name	Type	Flag	Description
target	STRING	-target	Single or multiple subdomains separated by comma.
targets	FILE	-targets	File of subdomains to scan, the usual pipeline input.
concurrency	STRING	-concurrency	Number of concurrent checks (default 10).
timeout	STRING	-timeout	Request timeout in seconds (default 10).
hide-fails	BOOLEAN	-hide_fails	Do not display non-vulnerable results.
force-https	BOOLEAN	-https	Force HTTPS when the target has no protocol defined.
dont-verify-ssl	BOOLEAN	-verify_ssl	Skip sites with insecure SSL instead of returning an HTTP error.

Showing key inputs. subzy exposes 7 inputs in total.

example

Run subzy

subzy · command

# scan a subdomain list, hide non-vulnerable hosts, raise concurrencysubzy -targets subdomains.txt -hide_fails -concurrency 50 -timeout 15

sample output

[ VULNERABLE - GitHub Pages ]  https://assets.example.com[ VULNERABLE - Amazon S3 ]     https://cdn.example.com[ NOT VULNERABLE ]             https://api.example.com[ NOT VULNERABLE ]             https://app.example.com[ NOT VULNERABLE ]             https://staging.example.com[ HTTP ERROR ]                 https://legacy.example.comResults  vulnerable: 2  not vulnerable: 3  errors: 1

guidance

Choosing subzy

Reach for subzy when you have a subdomain list and need to know which hosts are takeover candidates. It matches can-i-take-over-xyz fingerprints on live HTTP responses, so it confirms claimable pages rather than dangling CNAMEs alone. Pair with subfinder upstream; use tko-subs when you also want optional claim/takeover actions.

tko-subs

Also detects dangling DNS records and can claim some of them. Uses a providers CSV rather than the can-i-take-over-xyz fingerprint set.

subfinder

Finds the subdomains first. Run it before subzy, not instead of it.

nuclei

Has takeover templates among many other checks. subzy is purpose-built for this one fingerprint job.

faq

subzy questions

It requests the host, reads the response, and matches it against the fingerprint set from the can-i-take-over-xyz project. When the error page indicates a claimable, deprovisioned service, subzy marks the host vulnerable. Reading the live response rather than the CNAME alone cuts many false positives from DNS inspection alone.

Run subzy yourself

A domain feeds subfinder, which enumerates subdomains and passes them to subzy, which flags the takeover candidates as a queryable output.

Run subzy in Trickest View the workflow

Facts on this page come from the live Trickest tool library.

Name

Type

Flag

Description

target

STRING

-target

Single or multiple subdomains separated by comma.

targets

FILE

-targets

File of subdomains to scan, the usual pipeline input.

concurrency

STRING

-concurrency

Number of concurrent checks (default 10).

timeout

STRING

-timeout

Request timeout in seconds (default 10).

hide-fails

BOOLEAN

-hide_fails

Do not display non-vulnerable results.

force-https

BOOLEAN

-https

Force HTTPS when the target has no protocol defined.

dont-verify-ssl

BOOLEAN

-verify_ssl

Skip sites with insecure SSL instead of returning an HTTP error.

[ VULNERABLE - GitHub Pages ] https://assets.example.com[ VULNERABLE - Amazon S3 ] https://cdn.example.com[ NOT VULNERABLE ] https://api.example.com[ NOT VULNERABLE ] https://app.example.com[ NOT VULNERABLE ] https://staging.example.com[ HTTP ERROR ] https://legacy.example.comResults vulnerable: 2 not vulnerable: 3 errors: 1

Flag claimable dangling services on subdomains

What subzy does

Where subzy fits

Confirm takeovers across a discovered surface

Hunt dangling cloud and SaaS records

Keep takeover scans focused

Re-scan on a schedule to catch new exposure

subzy inputs and flags

Run subzy

Choosing subzy

tko-subs

subfinder

nuclei

subzy questions

More Vulnerabilities tools

commix

dnsreaper

find-gh-poc

jwt-tool

kxss

sqlmap

Run subzy yourself

Flag claimable dangling services on subdomains

What subzy does

Where subzy fits

Confirm takeovers across a discovered surface

Hunt dangling cloud and SaaS records

Keep takeover scans focused

Re-scan on a schedule to catch new exposure

subzy inputs and flags

Run subzy

Choosing subzy

tko-subs

subfinder

nuclei

subzy questions

More Vulnerabilities tools

commix

dnsreaper

find-gh-poc

jwt-tool

kxss

sqlmap

Run subzy yourself