hunt-tls-network

HUNT-TLS-NETWORK — TLS/SSL と DNS セキュリティ

現実を確認する（最初に読む）

この種の指摘のほとんどは、トリアージで「ベストプラクティス」／「ハードニング不足」としてInfo/Low と判定され、通常は却下されます。このスキルは、報告に時間を無駄にしないためのものです。ここで何かを報告する前に、次の2点を確認してください。

1. 実際の被害者と実際の行動がありますか？ 「HSTS がない」こと自体は脆弱性ではありません。MitM 攻撃を行った被害者からセッション Cookie を取得したことを実証できる場合は別です。「CAA がない」ことは、実証可能な脆弱性にはなりません。
2. プログラムは受け付けていますか？ 多くのプログラムでは、SPF/DMARC の欠如、セキュリティヘッダーの欠如、悪用を伴わない弱い暗号スイート、CAA を対象外と明記しています。まず対象範囲を確認し、報告には対象内であることを示す記述を引用してください。

この種の調査で実際に報奨金につながるもの（優先順）：

• ダングリング CNAME／ダングリング A によるサブドメイン乗っ取り — target.com のサブドメイン上のコンテンツを制御できます。実害があり、報奨金につながります。（詳細は hunt-subdomain が担当します。ここでは TLS/DNS の偵察という観点から扱います。）
• なりすまし可能な DMARC を、受信トレイへのメール到達で実証 — 「p=none が設定されている」ことではなく、[email protected] からの実際のメールが本物の受信トレイに届き、ヘッダーに DMARC の pass/none 判定があることです。
• 内部ホストを返す DNS AXFR — 内部のホスト名／IP アドレスの完全なマップが得られます。具体的な偵察価値があり、多くの場合 Medium です。
• 内部サービスでの mTLS／クライアント証明書のバイパス — 証明書なしで認証必須機能にアクセスできます。実際の認証バイパスは High です。
• 復号／MitM の実用的な PoC を伴う TLS の脆弱性の悪用 — 2024～2026 年に、パッチ適用済みのスタックに対してリモートから実現するのはほぼ不可能です。Phase 1 の注意事項を参照してください。

報告しても報奨金につながらないもの（単独では報告しないでください）： CAA の欠如、MitM の PoC を伴わない HSTS の欠如、セキュリティヘッダーの欠如のみ、悪用を伴わない弱い暗号スイートの サポート、本番環境ではないホストの自己署名証明書、ダウングレード攻撃の被害者を伴わない TLS 1.0/1.1 の 有効化。

---

Phase 1 — TLS/SSL の監査

# Quick TLS test with testssl.sh
brew install testssl
testssl.sh --fast $TARGET 2>/dev/null | grep -E "CRITICAL|HIGH|MEDIUM|OK|NOT" | head -30

# Or use sslyze (Python)
pip3 install sslyze
python3 -m sslyze $TARGET --json_out /tmp/sslyze_$TARGET.json 2>/dev/null
cat /tmp/sslyze_$TARGET.json | python3 -m json.tool | grep -i "vulnerability\|insecure\|error" | head -20

# 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"

正確性／トリアージに関する注意 — TLS のバグを誇張しないでください：

• 利用可能 ≠ 悪用可能。 testssl/sslyze が RC4、3DES、TLS 1.0 を検出しても、それはサーバーがそれらを ネゴシエートする という意味です。これはハードニング上の指摘であり、復号を実証したものではありません。PoC がなければ Info/Low となり、対象外とされることもよくあります。
• SWEET32（CVE-2016-2183） — 3DES の誕生日攻撃です。長時間継続する TLS セッション、経路上の攻撃者、同一鍵による数百 GB／数時間分のトラフィックが必要です。バグバウンティで実証するのは現実的ではありません。3DES の サポート のみを報告し、Low/Info の判定を想定してください。
• POODLE（CVE-2014-3566） — SSLv3 の CBC パディングオラクルです。SSLv3 が実際に有効である必要があります。最新のスタックのほとんどでは提供されていません。testssl.sh --poodle（または nmap --script ssl-poodle）で確認してください。最新の OpenSSL 3.x では -ssl3 フラグが削除されています。SSLv3 をネゴシエートできない場合、POODLE は発生しません。
• FREAK（CVE-2015-0204） と DROWN（CVE-2016-0800） — それぞれ、輸出グレードの RSA と、SSLv2 エンドポイントを共有していることが必要です。いずれも 存在を実証する 必要がある前提条件であり、あると仮定してはいけません。DROWN では、証明書／鍵を共有する いずれかの ホストで SSLv2 にアクセスできる必要があります。主張する前に、証明書の SAN リスト全体を対象に testssl.sh --drown（または nmap --script sslv2-drown）で SSLv2 をスキャンしてください。最新の OpenSSL には -ssl2 フラグはありません。
• Heartbleed（CVE-2014-0160） — パッチ未適用の OpenSSL 1.0.1 が実際にメモリを漏えいさせるのを発見した場合、実際の PoC（鍵／Cookie を含むダンプ）があれば、これは High/Critical に該当します。testssl.sh --heartbleed で確認し、漏えいしたバイトを取得してください。これは、完全な報告に値するまれな TLS バグです。

---

Phase 2 — HSTS の確認

# Check HSTS header on main domain and all subdomains
curl --max-time 30 --connect-timeout 10 -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 --max-time 30 --connect-timeout 10 -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 --max-time 30 --connect-timeout 10 -sI "http://$TARGET/" | grep -i "location"
# Should redirect to HTTPS immediately

# HSTS preload check
curl --max-time 30 --connect-timeout 10 -s "https://hstspreload.org/api/v2/status?domain=$TARGET" | python3 -m json.tool 2>/dev/null

---

Phase 3 — DNS ゾーン転送（AXFR）

# 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 alternativetools
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 — メールセキュリティ（SPF/DKIM/DMARC）

# 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  # Bulk: dnsx -silent -l file -a -resp-only TXT $TARGET | tr -d '"' | grep -i "v=spf1")
DMARC=$(dig +short  # Bulk: dnsx -silent -l file -a -resp-only 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

元の dig ... | wc -c | grep '^1$' チェックが機能しなかった理由： 空の dig +short # Bulk: dnsx -silent -l file -a -resp-only 出力は長さ 0 の文字列です。これを wc -c にパイプすると通常は 0 となり、前後の改行の扱いはシェルに依存するため、^1$ の一致判定はどちらの方向にも誤動作します。常に変数に格納し、[ -z "$VAR" ] で判定してください。

スプーフィング可能性は、レコードを読む作業ではなく受信側が判断します

dig の出力だけを根拠に「DMARC がない＝メールスプーフィング」と報告してはいけません。DMARC の p=none（または未設定）は、送信ドメインが強制措置を公開していないことを意味します。しかし、受信側のメールプロバイダー（Gmail、M365、プログラム独自の MX）は、SPF、独自のヒューリスティック、または ARC に基づいて、スプーフィングメールを迷惑メールに振り分けたり拒否したりする可能性があります。トリアージを経ても有効な唯一の証拠は、実際の受信トレイに配信されたメッセージです。

# 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 [email protected] \
      --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. メッセージが 受信トレイに届いたこと（迷惑メール／ジャンクではないこと）。フォルダーのスクリーンショットを撮ります。
2. 生のヘッダーに Authentication-Results: があり、dmarc=none|fail を示しているにもかかわらず、メールが配信済みであること（バウンスされていないこと）。バウンスや迷惑メールフォルダーへの振り分けは報告対象ではありません。その旨を記録して次に進みます。
3. 受信者に表示される From: が @$TARGET であること（フィッシングで重要なヘッダー From のスプーフィング）。単なる envelope-from の細工ではありません。

重要度は、受信トレイに配信された場合でも最大で Medium です。多くのプログラムでは、メール認証に関する報告は最初から対象外（OOS）とされます。まずスコープを確認してください。

---

フェーズ 5 — セキュリティヘッダーの監査

# Check all security headers
HEADERS=$(curl --max-time 30 --connect-timeout 10 -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 --max-time 30 --connect-timeout 10 -s "https://securityheaders.com/?q=https://$TARGET&followRedirects=on" | \
  grep -Eo "grade-\K[A-F+]" | head -3

---

フェーズ 6 — Certificate Transparency（サブドメインの発見）

# crt.sh — certificate transparency logs
curl --max-time 30 --connect-timeout 10 -s "https://crt.sh/?q=%25.$TARGET&output=json" | \
  python3 -m json.tool 2>/dev/null | grep "name_value" | \
  grep -Eo '"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

---

フェーズ 6.5 — 放置されたレコード → サブドメイン乗っ取り（実際に報奨金につながる脆弱性）

このスキル全体で最も影響の大きい項目です。CNAME／A レコードが、プロビジョニング解除済みのサードパーティリソース（S3 バケット、Azure CDN／App Service、GitHub Pages、Heroku、Fastly など）を指している場合、そのリソースを取得して *.target.com からコンテンツを配信できます。詳細は hunt-subdomain にあります。ここでは TLS／DNS 調査の入口を説明します。

# For each subdomain from CT logs, resolve the CNAME chain and check for a live origin
while read sub; do
  CNAME=$(dig +short  # Bulk: dnsx -silent -l file -a -resp-only CNAME "$sub" | head -1)
  [ -z "$CNAME" ] && continue
  CODE=$(curl -s -o /dev/null -w "%{http_code}" --max-time 8 --connect-timeout 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").

検証ゲート — 乗っ取りの主張には、実際にリソースを取得する必要があります。

1. 放置された接続先が未登録で、取得可能であることを確認します（S3 バケット名が空いている、Heroku アプリが存在しない、など）。プロバイダーのエラーを示すフィンガープリントだけでは必要条件を満たしますが、十分条件ではありません。
2. 自分でリソースを登録し、たとえば https://$sub/<random>.txt で、自分だけが知っている文字列を返す固有のカナリアファイルを配信します。有効な TLS を使い、対象サブドメイン経由で配信される様子をスクリーンショットに撮ります。
3. PoC の提示後、直ちにリソースを削除します。対象ドメイン上で攻撃者が制御するコンテンツを公開したままにしてはいけません。

影響：Cookie スコープの窃取（.target.com に設定された Cookie）、OAuth の redirect_uri／CORS 信頼の悪用、信頼されたオリジンでのフィッシング。通常は High（OAuth／SSO リダイレクト先に該当する場合、またはセッション Cookie を共有している場合は Critical）です。

---

フェーズ 7 — CAA レコード（偵察の手掛かりのみ — 報告対象ではありません）

# CAA records DECLARE which CAs the domain owner permits to issue certs.
dig CAA $TARGET +short
dig CAA "*.$TARGET" +short

「CAA がない」ことを脆弱性として報告してはいけません。 この種の調査で最もよくある誤検知です。正しくは、次のように説明します。

• CAA レコードがなくても、攻撃者が証明書を取得できるわけではありません。 それは、どの CA が証明書を発行できるかを制限する設定を、所有者が選択していないことを示すだけです。CAA の有無にかかわらず、攻撃者は依然としてドメイン制御の検証（HTTP-01／DNS-01／メール）を通過する必要があります。そのためには、すでにドメイン、DNS、またはウェブルートを制御していなければなりません。
• 「不正な証明書発行」のシナリオには、CA の侵害、または誤発行するよう CA をソーシャルエンジニアリングすることが必要です。これは、実質的にすべてのバグバウンティプログラムで対象外であり、実証できるものでもありません。CAA の強制は CA 側の制御であり、攻撃者に公開された攻撃対象領域ではありません。
• CAA は、せいぜい Info 相当のセキュリティ強化にすぎず、Won't-Fix／OOS として却下されることもよくあります。記載するとしても、偵察メモの付録にとどめ、単独の報告として提出してはいけません。

CAA の偵察が役立つ場面（報告対象ではなく、情報収集のみ）： issue／issuewild の値から、組織が利用している CA（例：letsencrypt.org、digicert.com、amazon.com）が分かります。これは自動化（ACME）の手掛かりになります。また、実際の乗っ取り（フェーズ 6.5 の放置されたレコード）でホストを制御できれば、DCV を通じて有効な証明書を発行できる可能性があることも示唆します。

---

フェーズ 8 — mTLS バイパスの試行

# Check if endpoint requires client certificate
curl --max-time 30 --connect-timeout 10 -sk "https://$TARGET/internal/" 2>&1 | grep -i "ssl\|certificate\|403\|401"

# Try without client cert (should fail)
curl --max-time 30 --connect-timeout 10 -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 --max-time 30 --connect-timeout 10 -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 --max-time 30 --connect-timeout 10 -sk "https://$TARGET/internal/api" -H "$H1" -H "$H2" -o /dev/null -w "%{http_code}\n"
done

mTLS バイパスの検証 — これは実際の認証バイパスなので、ステータスコードだけでなくアクセスできたことを証明してください：

• 200 は汎用ページを示している可能性があります。認証済みユーザー専用の機能に到達したことを確認してください。たとえば、クライアント証明書がなければ不可能なデータや操作（管理者専用のオブジェクト、内部専用のレスポンス本文など）を示してください。
• サーバーポリシーとサーバーの状態を区別してください。偽装したヘッダーによって 403 が 200 に変わるのは意味があります。一方、ヘッダーの有無にかかわらず 200 なら、そのパスはそもそも保護されていなかったことになります（報告対象なし）。
• バイパス経路（/health、/metrics）については、そのエンドポイントが機密データ（内部 IP、ビルドシークレット、内部トポロジーが分かる Prometheus メトリクスなど）を公開している場合に限り、報告対象となります。空の 200 OK を返すヘルスチェックは該当しません。
• Burp Repeater でリクエストとレスポンスのペアを取得し、偽装したヘッダーによって特権レスポンスが返されたことを明確に示してください。

---

脆弱性チェーン表

以下の深刻度は、トリアージで実際に受け入れられる水準に合わせています。意図的に控えめに設定しているため、レポートで深刻度を誇張しないでください。

TLS/DNS の指摘事項	単独の場合の現実的な深刻度	備考／深刻度が上がる条件
放置された CNAME によるサブドメインテイクオーバー（リソースを取得し、カナリアを配信）	高	OAuth の redirect_uri／SSO に関係する場合、または .target.com のセッション Cookie を共有している場合はクリティカル
mTLS／クライアント証明書のバイパスによる認証済み機能へのアクセス	高	200 が返るだけでなく、特権データ／操作を示す必要があります
AXFR による内部ホスト／IP の取得	中	偵察に役立ちます。内部サービスに関する指摘と組み合わせると効果的です
なりすまし可能な DMARC、実際の受信トレイへの配信を確認（PoC ヘッダーあり）	中	対象外（OOS）であることがよくあります — 対象範囲を確認してください。受信トレイ（迷惑メールではない）への配信確認が必要です。dig で p=none を確認しただけなら情報提供レベルであり、報告しないでください
Heartbleed／秘密情報を含む実際のメモリ漏えい	高～クリティカル	鍵／Cookie を含む実際のダンプがある場合に限ります
認証サブドメインにおける HSTS の欠如	低／情報提供	高ではありません — 悪用にはリモートから証明できない能動的な MitM の位置が必要です。動作するダウングレード取得 PoC がある場合に限り報告してください
復号 PoC がない弱い暗号スイートのサポート（RC4／3DES／SWEET32）	情報提供／低	セキュリティ強化のみの指摘です。対象外（OOS）であることもよくあります
CAA の欠如	情報提供（報告しない）	設定がないだけでは証明書の発行は可能になりません。攻撃者が実証できる指摘ではありません

---

ツール

# testssl.sh — comprehensive TLS audit
brew install testssl
testssl.sh $TARGET

# sslyze — Python TLS scanner
pip3 install sslyze

# MXToolbox for email security
curl --max-time 30 --connect-timeout 10 -s "https://mxtoolbox.com/api/v1/Lookup/spf?argument=$TARGET" 2>/dev/null

# dmarc-inspector
curl --max-time 30 --connect-timeout 10 -s "https://dmarcian.com/dmarc-inspector/?domain=$TARGET" 2>/dev/null

---

検証

各指摘には、記載されている証明のみを添付してください。dig の出力やヘッダーの出力だけでは不十分です。

• **サブドメインテイクオーバー：**放置されたリソースを取得し、有効な TLS を使って https://sub.target.com/ から一意のカナリアを配信してください。スクリーンショットとカナリア文字列を添付します。（確認後、リソースを削除してください。）
• **mTLS バイパス：**偽装したクライアント検証ヘッダーによって、証明書必須の経路では拒否される特権データ／操作が返されること。Burp のリクエスト／レスポンスのペアを添付します。
• **AXFR：**権威 NS からのゾーン転送で内部ホスト名／IP が返されること。トランスクリプト全体を添付します。
• DMARC のなりすまし：From: @target.com を指定したメールを swaks で送信し、実際の受信トレイに配信されること（迷惑メールではない）を確認します。生の Authentication-Results ヘッダーを添付します。バウンス、または迷惑メールへの振り分けは報告対象になりません。
• **HSTS の欠如：**被害者の Cookie を平文で取得する、動作するダウングレード PoC がある場合に限り報告できます。なければ、ベストプラクティスに関するノイズにすぎません。

深刻度（控えめな評価 — 脆弱性チェーン表に準拠）：

• サブドメインテイクオーバー（取得済み）：高（OAuth／SSO のリダイレクト、または共有セッション Cookie に関係する場合はクリティカル）
• 認証済み機能に到達する mTLS バイパス：高
• 内部ホストを返す AXFR：中
• 受信トレイへの配信を確認した DMARC のなりすまし：中（対象外（OOS）であることがよくあります — 対象範囲を確認してください）
• 認証環境における HSTS の欠如（ダウングレード PoC あり）：低～中。PoC がない場合：情報提供
• 復号 PoC がない弱い暗号スイートのサポート：情報提供～低
• セキュリティヘッダーの欠如／CAA の欠如のみ：情報提供（通常は報告しないでください）

**提出前の対象範囲確認：**ここに記載されている項目を報告する前に、プログラムで対象外とされていないことを必ず確認してください（メール認証、ヘッダーの欠如、悪用のない弱い TLS、CAA は対象外であることがよくあります）。レポートには対象範囲内であることを示す記載を引用してください。

---

検証

tls-network のハンティング準備ができていることを確認するため、次のセルフテストを実行します。

1. スキルの整合性 — スキルファイルが読み取り可能で、適切な形式であることを確認します。

   grep -q "name: hunt-tls-network" SKILL.md && echo "PASS: skill frontmatter present" || echo "FAIL"
   grep -q "revision_date:" SKILL.md && echo "PASS: revision date present" || echo "FAIL"
   

2. カテゴリの確認 — スキルにカテゴリが設定されていることを確認します。

   grep -q "category:" SKILL.md && echo "PASS: category present" || echo "FAIL"
   

3. 落とし穴のセクション — 落とし穴が記載されていることを確認します。

   grep -q "^## Pitfalls" SKILL.md && echo "PASS: pitfalls section present" || echo "FAIL"
   

3 つのテストすべてで、スキルが適切に構成され、使用する準備ができていることを確認します。

---

落とし穴

• 悪用手段を伴わない TLS バージョン — TLS 1.0／1.1 のサポートは設定上の指摘事項であり、脆弱性ではありません（特定のダウングレード攻撃を伴う場合を除きます）。
• 悪用手段を伴わない弱い暗号スイート — RC4、3DES などは脆弱ですが、悪用にはアクティブな中間者攻撃が必要です。攻撃シナリオを記録してください。
• 自己署名証明書 — 自己署名証明書は内部サービスでは一般的です。公開サービスの場合は、フィッシングのリスクとなります（低〜中）。
• 証明書透明性ログの監視 — CT ログからサブドメインを見つけるのは偵察であり、脆弱性ではありません。指摘すべきなのは、それらのサブドメインが公開しているものです。
• Heartbleed／POODLE のテスト — これらの旧式の TLS 脆弱性は、2024 年以降では極めてまれです。テストは行いますが、過度に時間をかけないでください。