HUNT-TLS-NETWORK — TLS/SSL & DNS Security

HUNT-TLS-NETWORK — TLS/SSL 与 DNS 安全

Reality Check (Read First)

现实检查（请先阅读）

Most findings in this class are Info/Low and routinely rejected as "best-practice" / "missing-hardening" by triage. This skill exists to stop you wasting a submission. Two questions before you report anything here:

Is there a real victim and a real action? "Missing HSTS" is not a vulnerability — demonstrated session-cookie capture from a victim you MitM'd is. "Missing CAA" is never a vulnerability you can demonstrate.
Does the program accept it? Many programs explicitly list missing SPF/DMARC, missing security headers, weak ciphers without exploit, and CAA as out of scope. Read scope first; quote the in-scope line in your report.

What actually pays in this class (in order):

Dangling-CNAME / dangling-A subdomain takeover — you control content on
```
target.com
```
subdomain. Real impact, real bounty. (Owned in depth by
```
hunt-subdomain
```
; covered here for the TLS/DNS recon angle.)
Spoofable DMARC, proven by delivered-to-inbox email — not "p=none exists" but an actual mail from
```
ceo@target.com
```
landing in a real inbox with a passing/none DMARC verdict in the headers.
DNS AXFR returning internal hosts — full internal hostname/IP map. Concrete recon value, often Medium.
mTLS / client-cert bypass on an internal service — reaching authenticated-only functionality without the cert. Real auth bypass = High.
Exploited TLS weakness with a working decrypt/MitM PoC — almost never achievable remotely in 2024-2026 against a patched stack; see Phase 1 caveats.

What does NOT pay (do not report standalone): missing CAA, missing HSTS with no MitM PoC, missing security headers alone, weak-cipher support without an exploit, self-signed cert on a non-prod host, TLS 1.0/1.1 enabled without a downgrade victim.

此类中的大多数发现属于 Info/Low，在 triage 阶段经常被当作“最佳实践”或“缺少加固”而遭到拒绝。这个 skill 的存在，是为了避免你浪费一次提交机会。提交此类发现前，请先回答两个问题：

是否存在真实的受害者和真实的攻击动作？ “缺少 HSTS”不是漏洞——能够证明你通过 MitM 截获了受害者的 session cookie 才是。“缺少 CAA”则永远不是可以实际证明的漏洞。
项目是否接受此类问题？ 许多项目会明确将缺少 SPF/DMARC、缺少安全响应头、不可利用的弱密码套件以及 CAA 列为 out of scope。先阅读 scope；在报告中引用 in-scope 条款的原文。

此类问题中真正有价值的内容（按优先级排序）：

Dangling-CNAME / dangling-A 子域名接管——你可以控制
```
target.com
```
某个子域名上的内容。影响真实，确实有赏金。（该方向由
```
hunt-subdomain
```
深入覆盖；这里从 TLS/DNS recon 角度进行处理。）
可欺骗的 DMARC，并由实际投递到收件箱的邮件证明——不是仅仅发现“存在
```
p=none
```
”，而是来自
```
ceo@target.com
```
的真实邮件进入了真实收件箱，且邮件头中的 DMARC 判定为 pass/none。
DNS AXFR 返回内部主机——可以获得完整的内部主机名/IP 映射。具备具体的 recon 价值，通常为 Medium。
内部服务上的 mTLS / client-cert 绕过——在没有证书的情况下访问仅允许通过认证的功能。真实的认证绕过属于 High。
已利用的 TLS 弱点，并提供有效的 decrypt/MitM PoC——在 2024—2026 年针对已修补的软件栈，几乎无法远程实现；请参阅 Phase 1 中的限制说明。

**不值得提交的内容（不要作为独立发现上报）：**缺少 CAA、没有 MitM PoC 时缺少 HSTS、仅缺少安全响应头、没有 exploit 时仅支持弱密码套件、非生产环境主机使用自签名证书，以及没有降级受害者时仅启用 TLS 1.0/1.1。

Phase 1 — TLS/SSL Audit

Phase 1 — TLS/SSL 审计

bash

undefined

bash

undefined

Quick TLS test with testssl.sh

Or use sslyze (Python)

Check certificate expiry and chain

echo | openssl s_client -connect $TARGET:443 -servername $TARGET 2>/dev/null |
openssl x509 -noout -dates -subject -issuer 2>/dev/null

Check for weak ciphers manually (a successful handshake = the cipher is OFFERED, not exploitable)

openssl s_client -connect $TARGET:443 -cipher RC4-SHA 2>/dev/null | grep -i "cipher|handshake" openssl s_client -connect $TARGET:443 -cipher DES-CBC3-SHA 2>/dev/null | grep -i "cipher|handshake"

Protocol downgrade surface — TLS 1.0/1.1 still negotiable?

openssl s_client -connect $TARGET:443 -tls1 2>/dev/null | grep -E "Protocol|Cipher" openssl s_client -connect $TARGET:443 -tls1_1 2>/dev/null | grep -E "Protocol|Cipher"


**Accuracy / triage notes — do not over-claim TLS bugs:**

- **Offered ≠ exploitable.** testssl/sslyze flagging RC4, 3DES, or TLS 1.0 means the server *negotiates* it. That is a hardening finding, **not** a demonstrated decrypt. Without a PoC it is Info/Low and frequently OOS.
- **SWEET32 (CVE-2016-2183)** — 3DES birthday attack. Requires a long-lived TLS session, an on-path attacker, and ~hundreds of GB / hours of same-key traffic. Realistically un-demonstrable in a bug bounty; report only the *support* of 3DES, expect Low/Info.
- **POODLE (CVE-2014-3566)** — SSLv3 CBC padding oracle. Needs **SSLv3 actually enabled**; almost no modern stack offers it. Confirm with `testssl.sh --poodle` (or `nmap --script ssl-poodle`) — modern OpenSSL 3.x dropped the `-ssl3` flag. If SSLv3 won't negotiate, there is no POODLE.
- **FREAK (CVE-2015-0204)** and **DROWN (CVE-2016-0800)** — require export-grade RSA / a shared SSLv2 endpoint respectively. Both are pre-conditions you must *prove present*, not assume. DROWN needs SSLv2 reachable on *some* host sharing the cert/key — scan for SSLv2 with `testssl.sh --drown` (or `nmap --script sslv2-drown`) across the cert's SAN list before claiming it; modern OpenSSL has no `-ssl2` flag.
- **Heartbleed (CVE-2014-0160)** — if you genuinely find an unpatched OpenSSL 1.0.1 leaking memory, that *is* High/Critical with a real PoC (dump containing keys/cookies). Verify with `testssl.sh --heartbleed` and capture leaked bytes; this is the rare TLS bug worth a full report.

---

openssl s_client -connect $TARGET:443 -tls1 2>/dev/null | grep -E "Protocol|Cipher" openssl s_client -connect $TARGET:443 -tls1_1 2>/dev/null | grep -E "Protocol|Cipher"


**准确性 / triage 注意事项——不要夸大 TLS 缺陷：**

- **支持某项算法不等于可以利用。** testssl/sslyze 标记 RC4、3DES 或 TLS 1.0，只表示服务器会协商使用它。这属于加固类发现，**并不等同于已经证明能够解密**。没有 PoC 时，它属于 Info/Low，而且经常是 OOS。
- **SWEET32（CVE-2016-2183）**——针对 3DES 的生日攻击。它需要长生命周期的 TLS 会话、路径上的攻击者，以及数百 GB、数小时的同密钥流量。在 bug bounty 中实际上无法证明；只能报告对 3DES 的支持，预期评级为 Low/Info。
- **POODLE（CVE-2014-3566）**——针对 SSLv3 CBC padding oracle 的攻击。前提是 **SSLv3 确实已启用**；几乎没有现代软件栈会提供 SSLv3。使用 `testssl.sh --poodle`（或 `nmap --script ssl-poodle`）确认。现代 OpenSSL 3.x 已移除 `-ssl3` flag。如果 SSLv3 无法完成协商，就不存在 POODLE。
- **FREAK（CVE-2015-0204）和 DROWN（CVE-2016-0800）**——分别要求存在 export-grade RSA 或共享的 SSLv2 endpoint。这两个前置条件都必须**证明确实存在**，不能凭空假设。DROWN 要求证书或密钥共享的**某个主机**上存在可访问的 SSLv2；在声称存在该问题前，应使用 `testssl.sh --drown`（或 `nmap --script sslv2-drown`）扫描证书 SAN 列表中的所有主机。现代 OpenSSL 没有 `-ssl2` flag。
- **Heartbleed（CVE-2014-0160）**——如果确实发现未修补的 OpenSSL 1.0.1 正在泄漏内存，则在提供真实 PoC（包含密钥或 Cookie 的 dump）后，确实属于 High/Critical。使用 `testssl.sh --heartbleed` 验证并捕获泄漏字节；这是极少数值得提交完整报告的 TLS 缺陷。

---

Phase 2 — HSTS Check

Phase 2 — HSTS 检查

bash

undefined

bash

undefined

Check HSTS header on main domain and all subdomains

curl -sI "https://$TARGET/" | grep -i "strict-transport-security"

Expected: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Check critical subdomains (login, api, auth)

for sub in login auth api account pay www; do HSTS=$(curl -sI "https://$sub.$TARGET/" 2>/dev/null | grep -i "strict-transport-security") if [ -z "$HSTS" ]; then echo "[!] MISSING HSTS: https://$sub.$TARGET/" else echo "[OK] $sub.$TARGET: $HSTS" fi done

Check HTTP (non-HTTPS) redirect

curl -sI "http://$TARGET/" | grep -i "location"

Should redirect to HTTPS immediately

HSTS preload check

curl -s "https://hstspreload.org/api/v2/status?domain=$TARGET" | python3 -m json.tool 2>/dev/null

---

curl -s "https://hstspreload.org/api/v2/status?domain=$TARGET" | python3 -m json.tool 2>/dev/null

---

Phase 3 — DNS Zone Transfer (AXFR)

Phase 3 — DNS 区域传送（AXFR）

bash

undefined

bash

undefined

Find nameservers

dig NS $TARGET +short

Attempt zone transfer on each nameserver

for NS in $(dig NS $TARGET +short); do echo "=== Trying AXFR from $NS ===" dig AXFR $TARGET @$NS 2>/dev/null | grep -v "^;" | head -30 done

Zone transfer via alternative tools

host -t AXFR $TARGET $(dig NS $TARGET +short | head -1) 2>/dev/null | head -30 nmap -sn --script dns-zone-transfer $TARGET 2>/dev/null | head -30

If AXFR succeeds → full internal hostname map

Look for: internal IPs, staging servers, admin hostnames, CI/CD servers

---

---

Phase 4 — Email Security (SPF/DKIM/DMARC)

Phase 4 — 邮件安全（SPF/DKIM/DMARC）

bash

undefined

bash

undefined

Check SPF record

dig TXT $TARGET +short | grep "v=spf1"

Missing SPF → potential email spoofing

Check DMARC

dig TXT _dmarc.$TARGET +short

Missing DMARC → attacker can send as @target.com with no enforcement

Check DKIM selectors (common: default, google, mail, k1)

for selector in default google mail k1 selector1 selector2 s1 s2 dkim; do RESULT=$(dig TXT $selector._domainkey.$TARGET +short 2>/dev/null) [ -n "$RESULT" ] && echo "DKIM selector found: $selector → $RESULT" done

--- Spoofability evaluation (heuristic only; PROOF is the swaks test below) ---

SPF=$(dig +short TXT $TARGET | tr -d '"' | grep -i "v=spf1") DMARC=$(dig +short TXT _dmarc.$TARGET | tr -d '"' | grep -i "v=DMARC1")

SPF "+all" / "all" with no qualifier = pass-everything = spoofable from any IP

echo "$SPF" | grep -Eq '[+ ]all($|[^-~?])' && echo "[CRITICAL] SPF passes all senders (+all)" echo "$SPF" | grep -q "~all" && echo "[INFO] SPF softfail (~all) — may still deliver to inbox" [ -z "$SPF" ] && echo "[INFO] No SPF record"

Correct DMARC-absence check: test the variable for emptiness, do NOT pipe dig|wc -c

if [ -z "$DMARC" ]; then echo "[INFO] No DMARC record (no published policy)" else POLICY=$(echo "$DMARC" | grep -oiE 'p=[a-z]+' | head -1) echo "[INFO] DMARC present: $POLICY" echo "$POLICY" | grep -qi "p=none" && echo " -> p=none: monitors only, does NOT block spoofed mail" echo "$POLICY" | grep -qiE "p=(quarantine|reject)" && echo " -> enforcing policy: spoofing likely blocked at receiver" fi


**Why the original `dig ... | wc -c | grep '^1$'` check was broken:** empty `dig +short` output is a zero-length string; piped through `wc -c` it usually yields `0`, and the surrounding newline handling is shell-dependent, so the `^1$` match misfires both ways. Always capture into a variable and test `[ -z "$VAR" ]`.

if [ -z "$DMARC" ]; then echo "[INFO] No DMARC record (no published policy)" else POLICY=$(echo "$DMARC" | grep -oiE 'p=[a-z]+' | head -1) echo "[INFO] DMARC present: $POLICY" echo "$POLICY" | grep -qi "p=none" && echo " -> p=none: monitors only, does NOT block spoofed mail" echo "$POLICY" | grep -qiE "p=(quarantine|reject)" && echo " -> enforcing policy: spoofing likely blocked at receiver" fi


**原始 `dig ... | wc -c | grep '^1$'` 检查为什么是错误的：**空的 `dig +short` 输出是零长度字符串；传入 `wc -c` 后通常会得到 `0`，而周围换行的处理方式又取决于 shell，因此 `^1$` 匹配会在两个方向上发生误判。应始终先将结果捕获到变量中，再使用 `[ -z "$VAR" ]` 测试。

Spoofability is a RECEIVER decision, not a record-reading exercise

可欺骗性由接收方决定，而不是读取记录就能确定

Do not report "missing DMARC = email spoofing" from

dig

output alone. DMARC

p=none

(or absent) means the sending domain published no enforcement — but the receiving mail provider (Gmail, M365, the program's own MX) may still junk or reject your spoof based on SPF, its own heuristics, or ARC. The only proof that survives triage is a message you delivered to a real inbox.

bash

undefined

不要仅凭

dig

输出就报告“缺少 DMARC = 电子邮件欺骗”。DMARC

p=none

（或缺少 DMARC）意味着发件域没有发布执行策略，但接收方邮件服务（Gmail、M365、项目自己的 MX）仍可能根据 SPF、自身启发式规则或 ARC 将欺骗邮件投入垃圾箱或直接拒绝。唯一能够通过 triage 的证据，是实际投递到真实收件箱的邮件。

bash

undefined

PROOF: send a spoofed mail and confirm INBOX delivery (use a tester account you own)

Use an account on the receiver the program actually uses (check their MX: dig MX $TARGET)

swaks --to your-tester@gmail.com
--from "CEO <ceo@$TARGET>"
--header "Subject: [TEST] DMARC spoof PoC for $TARGET"
--body "Authorized bug-bounty test. Spoofed from-domain: $TARGET"
--server <an-smtp-relay-you-control-or-localhost>


**Confirmation gate — a spoof PoC is only valid if you can show:**
1. The message landed in **Inbox** (not Spam/Junk), screenshot the folder.
2. The raw headers: `Authentication-Results:` showing `dmarc=none|fail` AND the mail was still **delivered** (not bounced). A bounce or a Spam-folder landing is NOT a finding — note it and move on.
3. The visible `From:` shows `@$TARGET` to the recipient (header-from spoof, the one that matters for phishing), not just an `envelope-from` trick.

Severity is **Medium at best**, and only if delivered-to-inbox. Many programs mark email-auth findings OOS outright — check scope first.

---

swaks --to your-tester@gmail.com
--from "CEO <ceo@$TARGET>"
--header "Subject: [TEST] DMARC spoof PoC for $TARGET"
--body "Authorized bug-bounty test. Spoofed from-domain: $TARGET"
--server <an-smtp-relay-you-control-or-localhost>


**确认门槛——只有满足以下条件，欺骗 PoC 才有效：**
1. 邮件进入了 **Inbox**，而不是 Spam/Junk；请对所在文件夹截图。
2. 原始邮件头中的 `Authentication-Results:` 显示 `dmarc=none|fail`，并且邮件仍然**成功投递**，而不是被退回。退回或进入 Spam 文件夹都不算发现；记录后继续下一步。
3. 收件人看到的 `From:` 显示为 `@$TARGET`（即对钓鱼真正重要的 header-from 欺骗），而不只是使用 `envelope-from` 技巧。

严重性最多为 **Medium**，并且必须证明邮件已进入收件箱。许多项目会将邮件认证类发现直接列为 OOS——请先检查 scope。

---

Phase 5 — Security Headers Audit

Phase 5 — 安全响应头审计

bash

undefined

bash

undefined

Check all security headers

HEADERS=$(curl -sI "https://$TARGET/")

Check each critical header

for HEADER in "Strict-Transport-Security" "Content-Security-Policy" "X-Frame-Options"
"X-Content-Type-Options" "Referrer-Policy" "Permissions-Policy"; do RESULT=$(echo "$HEADERS" | grep -i "$HEADER") if [ -z "$RESULT" ]; then echo "[MISSING] $HEADER" else echo "[OK] $HEADER: $RESULT" fi done

Automated security headers check

curl -s "https://securityheaders.com/?q=https://$TARGET&followRedirects=on" |
grep -oP "grade-\K[A-F+]" | head -3

---

curl -s "https://securityheaders.com/?q=https://$TARGET&followRedirects=on" |
grep -oP "grade-\K[A-F+]" | head -3

---

Phase 6 — Certificate Transparency (Subdomain Discovery)

Phase 6 — Certificate Transparency（子域名发现）

bash

undefined

bash

undefined

crt.sh — certificate transparency logs

curl -s "https://crt.sh/?q=%25.$TARGET&output=json" |
python3 -m json.tool 2>/dev/null | grep "name_value" |
grep -oP '"name_value": "\K[^"]+' |
sed 's/*.//g' | sort -u > recon/$TARGET/ct-subdomains.txt

echo "[+] CT subdomains found: $(wc -l < recon/$TARGET/ct-subdomains.txt)"

curl -s "https://crt.sh/?q=%25.$TARGET&output=json" |
python3 -m json.tool 2>/dev/null | grep "name_value" |
grep -oP '"name_value": "\K[^"]+' |
sed 's/*.//g' | sort -u > recon/$TARGET/ct-subdomains.txt

echo "[+] CT subdomains found: $(wc -l < recon/$TARGET/ct-subdomains.txt)"

Compare with existing subdomain list

comm -23 <(sort recon/$TARGET/ct-subdomains.txt)
<(sort recon/$TARGET/subdomains.txt 2>/dev/null) | head -20

New entries = recently issued certs = new services to investigate

---

---

Phase 6.5 — Dangling Records → Subdomain Takeover (the finding that actually pays)

Phase 6.5 — 悬空记录 → 子域名接管（真正有价值的发现）

This is the highest-impact item in the whole skill. A CNAME/A record pointing at a deprovisioned third-party resource (S3 bucket, Azure CDN/App Service, GitHub Pages, Heroku, Fastly, etc.) lets you claim that resource and serve content from

*.target.com

. Full depth lives in

hunt-subdomain

; here is the TLS/DNS-recon entry point.

bash

undefined

这是整个 skill 中影响最大的项目。指向已下线第三方资源（S3 bucket、Azure CDN/App Service、GitHub Pages、Heroku、Fastly 等）的 CNAME/A record，会让你能够认领该资源，并从

*.target.com

提供内容。深入内容由

hunt-subdomain

负责；这里仅介绍 TLS/DNS recon 入口。

bash

undefined

For each subdomain from CT logs, resolve the CNAME chain and check for a live origin

while read sub; do CNAME=$(dig +short CNAME "$sub" | head -1) [ -z "$CNAME" ] && continue CODE=$(curl -s -o /dev/null -w "%{http_code}" --max-time 8 "https://$sub/" 2>/dev/null) echo "$sub -> $CNAME [http $CODE]" done < recon/$TARGET/ct-subdomains.txt | tee recon/$TARGET/cname-map.txt

Flag CNAMEs that point at known takeoverable providers, then confirm the

fingerprint string in the body (e.g. "NoSuchBucket", "There isn't a GitHub Pages site here",

"Fastly error: unknown domain", "The specified bucket does not exist", Azure "Web App - Unavailable").


**Validation gate — a takeover claim requires you to actually claim it:**
1. Confirm the dangling target is **unregistered/claimable** (the S3 bucket name is free, the Heroku app does not exist, etc.) — the provider error fingerprint alone is necessary but NOT sufficient.
2. **Register the resource yourself** and serve a unique canary file, e.g. `https://$sub/<random>.txt` returning a string only you know. Screenshot it served over the victim subdomain with valid TLS.
3. Tear it down immediately after PoC; never leave attacker-controlled content live on the target's domain.

Impact: cookie scope theft (cookies set for `.target.com`), OAuth `redirect_uri`/CORS-trust abuse, phishing on a trusted origin. Typically **High** (Critical if it sits at an OAuth/SSO redirect or shares session cookies).

---


**验证门槛——声称存在接管问题必须实际完成认领：**
1. 确认悬空目标**尚未注册或可以认领**（例如 S3 bucket 名称可用、Heroku app 不存在）。仅出现服务商错误指纹是必要条件，但**并不充分**。
2. **自行注册该资源**并提供唯一的 canary 文件，例如让 `https://$sub/<random>.txt` 返回一段只有你知道的字符串。截图证明它已通过有效 TLS 在受害者的子域名上提供。
3. 完成 PoC 后立即拆除；绝不能将攻击者控制的内容长期留在目标域名上。

影响包括窃取 Cookie 作用域、滥用 OAuth `redirect_uri`/CORS 信任，以及在可信源上实施钓鱼。通常为 **High**；如果它位于 OAuth/SSO redirect 上或共享 session cookie，则为 Critical。

---

Phase 7 — CAA Records (recon signal only — NOT a reportable finding)

Phase 7 — CAA 记录（仅用于 recon，不是可报告的发现）

bash

undefined

bash

undefined

CAA records DECLARE which CAs the domain owner permits to issue certs.

dig CAA $TARGET +short dig CAA "*.$TARGET" +short


**Do NOT report "missing CAA" as a vulnerability.** This is the most common false positive in this class. Correct framing:

- A **missing CAA record does not let any attacker obtain a certificate.** It only means the owner has not *opted into* restricting which CAs may issue. With or without CAA, an attacker still needs to pass Domain Control Validation (HTTP-01 / DNS-01 / email) — which requires already controlling the domain, DNS, or web root.
- The "fraudulent issuance" scenario requires **CA compromise or social-engineering a CA** into mis-issuing. That is out of scope for essentially every bug-bounty program and is not something you can demonstrate. CAA enforcement is a CA-side control, not an attacker-facing surface.
- CAA is **Info-tier hardening at most**, and routinely closed as Won't-Fix / OOS. Mention it in a recon notes appendix if at all; never file it standalone.

**Where CAA recon IS useful (no finding, just intel):** the `issue`/`issuewild` values tell you which CA the org uses (e.g. `letsencrypt.org`, `digicert.com`, `amazon.com`). That hints at automation (ACME) and at where a *real* takeover (Phase 6.5 dangling records) could let you mint a valid cert via DCV because you'd control the host.

---

dig CAA $TARGET +short dig CAA "*.$TARGET" +short


**不要将“缺少 CAA”作为漏洞报告。**这是此类问题中最常见的误报。正确的表述是：

- **缺少 CAA record 不会让任何攻击者获得证书。**它只意味着域名所有者尚未选择限制哪些 CA 可以签发证书。无论是否存在 CAA，攻击者仍然必须通过 Domain Control Validation（HTTP-01 / DNS-01 / email），而这要求攻击者已经控制该域名、DNS 或 Web 根目录。
- “欺诈性签发”场景要求 **CA 被攻破，或攻击者通过社会工程手段诱使 CA 错误签发证书**。这几乎超出了所有 bug bounty 项目的范围，也不是能够实际证明的问题。CAA 执行属于 CA 侧控制，并不是面向攻击者的攻击面。
- CAA **最多属于 Info 级加固问题**，并且经常以 Won't-Fix 或 OOS 关闭。如果需要提及，请放在 recon 笔记附录中；绝不要单独提交。

**CAA recon 真正有用的地方（不构成发现，只提供情报）：**`issue`/`issuewild` 值会说明该组织使用哪个 CA，例如 `letsencrypt.org`、`digicert.com`、`amazon.com`。这可以提示其自动化机制（ACME），也可以指出 Phase 6.5 中的真实接管在控制主机后可能通过 DCV 签发有效证书的位置。

---

Phase 8 — mTLS Bypass Attempts

Phase 8 — mTLS 绕过尝试

bash

undefined

bash

undefined

Check if endpoint requires client certificate

curl -sk "https://$TARGET/internal/" 2>&1 | grep -i "ssl|certificate|403|401"

Try without client cert (should fail)

curl -sk --cert "" "https://$TARGET/internal/api" | head -5

Try common bypass paths (some apps skip mTLS on health checks)

for path in /health /ping /status /metrics /api/health; do STATUS=$(curl -sk -o /dev/null -w "%{http_code}" "https://$TARGET$path") echo "$path: $STATUS" done

Header-injection bypass — nginx/HAProxy/Envoy commonly terminate mTLS at the edge and

forward the verdict as a request header the backend trusts. If the edge does NOT strip

client-supplied copies of that header, you spoof a verified client. Try the real header

names used by each proxy:

for combo in
"X-SSL-Client-Verify: SUCCESS|X-SSL-Client-S-DN: CN=admin"
"ssl-client-verify: SUCCESS|ssl-client-subject-dn: CN=admin"
"X-Client-Verify: SUCCESS|X-Client-DN: CN=admin,O=target"
"X-Forwarded-Client-Cert: By=spiffe://x;Hash=0;Subject="CN=admin""; do H1="${combo%%|}"; H2="${combo##|}" echo "== $H1 / $H2 ==" curl -sk "https://$TARGET/internal/api" -H "$H1" -H "$H2" -o /dev/null -w "%{http_code}\n" done


**mTLS-bypass validation — this is a real auth bypass, so prove access, not just a status code:**
- A `200` could be a generic page. Confirm you reached **authenticated-only functionality**: show data/an action that is impossible without the client cert (e.g. an admin-only object, an internal-only response body).
- Distinguish *server policy* from *server state*: a `403` flipping to `200` with the spoofed header is meaningful; a `200` for both with and without the header means the path was never protected (no finding).
- For the bypass-path angle (`/health`, `/metrics`): only a finding if that endpoint exposes **sensitive data** (internal IPs, build secrets, Prometheus metrics revealing internal topology) — an empty `200 OK` health probe is not.
- Capture the request/response pair in Burp Repeater so the spoofed header → privileged response is unambiguous.

---

for combo in
"X-SSL-Client-Verify: SUCCESS|X-SSL-Client-S-DN: CN=admin"
"ssl-client-verify: SUCCESS|ssl-client-subject-dn: CN=admin"
"X-Client-Verify: SUCCESS|X-Client-DN: CN=admin,O=target"
"X-Forwarded-Client-Cert: By=spiffe://x;Hash=0;Subject="CN=admin""; do H1="${combo%%|}"; H2="${combo##|}" echo "== $H1 / $H2 ==" curl -sk "https://$TARGET/internal/api" -H "$H1" -H "$H2" -o /dev/null -w "%{http_code}\n" done


**mTLS 绕过验证——这是真实的认证绕过，因此必须证明获得了访问权限，而不能只观察状态码：**
- `200` 可能只是通用页面。必须确认你访问到了**仅允许通过认证的功能**：展示没有 client certificate 时不可能获得的数据或执行的操作，例如仅限管理员访问的对象或内部专用响应正文。
- 要区分*服务端策略*与*服务端状态*：如果 `403` 在伪造 header 后变为 `200`，就具有实际意义；如果有无该 header 时都返回 `200`，说明该路径从未受到保护，不构成发现。
- 对于绕过路径方向（`/health`、`/metrics`），只有 endpoint 暴露**敏感数据**时才算发现，例如内部 IP、构建密钥，或能够揭示内部拓扑的 Prometheus metrics；空的 `200 OK` health probe 不算。
- 在 Burp Repeater 中捕获请求/响应对，确保“伪造 header → 特权响应”的关系毫无歧义。

---

Chain Table

链式路径表

Severities below are calibrated to what triage actually accepts. They are deliberately conservative; do not inflate them in a report.

TLS/DNS finding	Realistic standalone severity	Notes / what raises it
Dangling-CNAME subdomain takeover (claimed + canary served)	High	Critical if at OAuth `redirect_uri` /SSO or sharing `.target.com` session cookies
mTLS / client-cert bypass reaching authed functionality	High	Must show privileged data/action, not just a 200
AXFR returning internal hosts/IPs	Medium	Recon value; pairs with internal-service findings
Spoofable DMARC, delivered to a real inbox (PoC headers)	Medium	Often OOS — check scope; Inbox (not Spam) + delivered required. Reading `p=none` from `dig` alone = Info, do not file
Heartbleed / live memory leak with captured secrets	High–Critical	Only with an actual dump containing keys/cookies
Missing HSTS on auth subdomain	Low / Info	NOT High — exploitation needs an active MitM position you cannot demonstrate remotely; report only with a working downgrade-capture PoC
Weak cipher support (RC4/3DES/SWEET32) with no decrypt PoC	Info / Low	Hardening only; frequently OOS
Missing CAA	Info (do not file)	Absence does not enable issuance; not attacker-demonstrable

以下严重性根据 triage 实际可接受的结果进行了校准。它们有意保持保守；不要在报告中夸大评级。

TLS/DNS 发现	现实的独立严重性	备注／提升因素
Dangling-CNAME 子域名接管（已成功认领并提供 canary）	High	如果位于 OAuth `redirect_uri` /SSO 或共享 `.target.com` session cookie，则为 Critical
mTLS / client-cert 绕过并访问已认证功能	High	必须展示特权数据或操作，不能只展示 200
AXFR 返回内部主机/IP	Medium	具有 recon 价值；可与内部服务发现结合
可欺骗的 DMARC，且已投递到真实收件箱（附 PoC 邮件头）	Medium	经常是 OOS——检查 scope；必须进入 Inbox（不能是 Spam）并成功投递。仅从 `dig` 读取到 `p=none` = Info，不要提交
Heartbleed / 实时内存泄漏并捕获到敏感信息	High–Critical	必须提供实际 dump，其中包含密钥或 Cookie
认证子域名缺少 HSTS	Low / Info	不是 High——利用需要主动处于 MitM 位置，而远程通常无法证明；仅在工作降级 PoC 捕获到受害者 Cookie 时才可报告
仅支持弱密码套件（RC4/3DES/SWEET32），没有解密 PoC	Info / Low	仅为加固问题；经常是 OOS
缺少 CAA	Info（不要提交）	缺少它不会促成证书签发；无法由攻击者实际证明

Tools

工具

bash

undefined

bash

undefined

testssl.sh — comprehensive TLS audit

brew install testssl testssl.sh $TARGET

sslyze — Python TLS scanner

pip3 install sslyze

MXToolbox for email security

curl -s "https://mxtoolbox.com/api/v1/Lookup/spf?argument=$TARGET" 2>/dev/null

dmarc-inspector

curl -s "https://dmarcian.com/dmarc-inspector/?domain=$TARGET" 2>/dev/null

---

curl -s "https://dmarcian.com/dmarc-inspector/?domain=$TARGET" 2>/dev/null

---

Validation

验证

Each finding ships only with the proof listed — never the

dig

/header output alone.

Subdomain takeover: you registered the dangling resource and served a unique canary over
```
https://sub.target.com/
```
with valid TLS. Screenshot + canary string. (Tear down after.)
mTLS bypass: spoofed client-verify header returns privileged data/action that the cert-required path otherwise denies. Burp request/response pair.
AXFR: zone transfer returns internal hostnames/IPs from an authoritative NS. Full transcript.
DMARC spoof: swaks-sent mail with
```
From: @target.com
```
delivered to a real Inbox (not Spam), raw
```
Authentication-Results
```
headers attached. A bounce or Spam landing = no finding.
HSTS missing: only reportable with a working downgrade PoC capturing a victim cookie over plaintext — otherwise it is best-practice noise.

Severity (conservative — matches the Chain Table):

Subdomain takeover (claimed): High (Critical at OAuth/SSO redirect or shared session cookie)
mTLS bypass to authed functionality: High
AXFR returning internal hosts: Medium
DMARC spoof delivered-to-inbox: Medium (often OOS — verify scope)
HSTS missing on auth (with downgrade PoC): Low–Medium; without PoC: Info
Weak cipher support without decrypt PoC: Info–Low
Missing security headers / missing CAA only: Info (usually do not file)

Pre-submission scope gate: before filing ANY item here, confirm the program does not list it as out of scope (email-auth, missing-headers, weak-TLS-without-exploit, and CAA are commonly OOS). Quote the in-scope line in your report.

每项发现都必须附带列出的证据——绝不能只提供

dig

或响应头输出。

**子域名接管：**你已注册悬空资源，并通过
```
https://sub.target.com/
```
在有效 TLS 下提供唯一 canary。提供截图和 canary 字符串。（完成后立即拆除。）
mTLS 绕过：伪造 client-verify header 后返回了原本需要证书才能访问的特权数据或操作。提供 Burp 请求/响应对。
**AXFR：**权威 NS 返回了内部主机名/IP。提供完整记录。
DMARC 欺骗：使用 swaks 发送、
From: @target.com
且进入真实 Inbox（不能进入 Spam）的邮件，并附上原始
```
Authentication-Results
```
邮件头。退回或进入 Spam 不算发现。
**缺少 HSTS：**只有提供工作降级 PoC 并通过明文捕获到受害者 Cookie 时才可报告；否则只是最佳实践噪声。

严重性（保守——与链式路径表一致）：

子域名接管（已成功认领）：High；位于 OAuth/SSO redirect 或共享 session cookie 时为 Critical
mTLS 绕过并访问已认证功能：High
AXFR 返回内部主机：Medium
DMARC 欺骗并投递到收件箱：Medium（经常是 OOS——验证 scope）
认证功能缺少 HSTS：有降级 PoC 时为 Low–Medium；没有 PoC 时为 Info
仅支持弱密码套件且没有解密 PoC：Info–Low
仅缺少安全响应头或 CAA：Info（通常不要提交）

**提交前 scope 门槛：**提交这里的任何项目之前，都要确认项目没有将其列为 out of scope（邮件认证、缺少响应头、没有 exploit 的弱 TLS，以及 CAA 经常属于 OOS）。在报告中引用 in-scope 条款的原文。

hunt-tls-network

Original

Translation

HUNT-TLS-NETWORK — TLS/SSL & DNS Security

HUNT-TLS-NETWORK — TLS/SSL 与 DNS 安全

Reality Check (Read First)

现实检查（请先阅读）

Phase 1 — TLS/SSL Audit

Phase 1 — TLS/SSL 审计

Quick TLS test with testssl.sh

Quick TLS test with testssl.sh

Or use sslyze (Python)

Or use sslyze (Python)

Check certificate expiry and chain

Check certificate expiry and chain

Check for weak ciphers manually (a successful handshake = the cipher is OFFERED, not exploitable)

Check for weak ciphers manually (a successful handshake = the cipher is OFFERED, not exploitable)

Protocol downgrade surface — TLS 1.0/1.1 still negotiable?

Protocol downgrade surface — TLS 1.0/1.1 still negotiable?

Phase 2 — HSTS Check

Phase 2 — HSTS 检查

Check HSTS header on main domain and all subdomains

Check HSTS header on main domain and all subdomains

Expected: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Expected: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Check critical subdomains (login, api, auth)

Check critical subdomains (login, api, auth)

Check HTTP (non-HTTPS) redirect

Check HTTP (non-HTTPS) redirect

Should redirect to HTTPS immediately

Should redirect to HTTPS immediately

HSTS preload check

HSTS preload check

Phase 3 — DNS Zone Transfer (AXFR)

Phase 3 — DNS 区域传送（AXFR）

Find nameservers

Find nameservers

Attempt zone transfer on each nameserver

Attempt zone transfer on each nameserver

Zone transfer via alternative tools

Zone transfer via alternative tools

If AXFR succeeds → full internal hostname map

If AXFR succeeds → full internal hostname map

Look for: internal IPs, staging servers, admin hostnames, CI/CD servers

Look for: internal IPs, staging servers, admin hostnames, CI/CD servers

Phase 4 — Email Security (SPF/DKIM/DMARC)

Phase 4 — 邮件安全（SPF/DKIM/DMARC）

Check SPF record

Check SPF record

Missing SPF → potential email spoofing

Missing SPF → potential email spoofing

Check DMARC

Check DMARC

Missing DMARC → attacker can send as @target.com with no enforcement

Missing DMARC → attacker can send as @target.com with no enforcement

Check DKIM selectors (common: default, google, mail, k1)

Check DKIM selectors (common: default, google, mail, k1)

--- Spoofability evaluation (heuristic only; PROOF is the swaks test below) ---

--- Spoofability evaluation (heuristic only; PROOF is the swaks test below) ---

SPF "+all" / "all" with no qualifier = pass-everything = spoofable from any IP

SPF "+all" / "all" with no qualifier = pass-everything = spoofable from any IP

Correct DMARC-absence check: test the variable for emptiness, do NOT pipe dig|wc -c

Correct DMARC-absence check: test the variable for emptiness, do NOT pipe dig|wc -c

Spoofability is a RECEIVER decision, not a record-reading exercise

可欺骗性由接收方决定，而不是读取记录就能确定

PROOF: send a spoofed mail and confirm INBOX delivery (use a tester account you own)

PROOF: send a spoofed mail and confirm INBOX delivery (use a tester account you own)

Use an account on the receiver the program actually uses (check their MX: dig MX $TARGET)

Use an account on the receiver the program actually uses (check their MX: dig MX $TARGET)

Phase 5 — Security Headers Audit

Phase 5 — 安全响应头审计

Check all security headers

Check all security headers

Check each critical header

Check each critical header

Automated security headers check

Automated security headers check

Phase 6 — Certificate Transparency (Subdomain Discovery)

Phase 6 — Certificate Transparency（子域名发现）

crt.sh — certificate transparency logs