hunt-tls-network – skill Marketing & SEO cho agent AI

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

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:

1. 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.

2. 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 [email protected] 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.

---

Phase 1 — TLS/SSL Audit

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

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.

---

Phase 2 — HSTS Check

# 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 Zone Transfer (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 — Email Security (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

Why the original dig ... | wc -c | grep '^1$' check was broken: empty dig +short # Bulk: dnsx -silent -l file -a -resp-only 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" ].

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.

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

**Confirmation

… (nội dung đầy đủ có trong gói tải về)