From claude-bughunter
Hunts TLS/SSL and DNS misconfigurations (HSTS, weak ciphers, expired certs, mTLS bypass, SPF/DKIM/DMARC, AXFR, dangling CNAME) and triages which findings are worth reporting vs best-practice noise.
How this skill is triggered — by the user, by Claude, or both
Slash command
/claude-bughunter:hunt-tls-networkThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
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:
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:
What actually pays in this class (in order):
target.com subdomain. Real impact, real bounty. (Owned in depth by hunt-subdomain; covered here for the TLS/DNS recon angle.)[email protected] landing in a real inbox with a passing/none DMARC verdict in the headers.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.
# 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:
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.testssl.sh --drown (or nmap --script sslv2-drown) across the cert's SAN list before claiming it; modern OpenSSL has no -ssl2 flag.testssl.sh --heartbleed and capture leaked bytes; this is the rare TLS bug worth a full report.# 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
# 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
# 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" ].
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 gate — a spoof PoC is only valid if you can show:
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.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.
# 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
# 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)"
# 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
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.
# 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:
https://$sub/<random>.txt returning a string only you know. Screenshot it served over the victim subdomain with valid TLS.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).
# 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:
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.
# 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:
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).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)./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.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 |
# 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
Each finding ships only with the proof listed — never the dig/header output alone.
https://sub.target.com/ with valid TLS. Screenshot + canary string. (Tear down after.)From: @target.com delivered to a real Inbox (not Spam), raw Authentication-Results headers attached. A bounce or Spam landing = no finding.Severity (conservative — matches the Chain Table):
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.
npx claudepluginhub elementalsouls/claude-bughunterReviews DNS sender-authentication records (SPF, DKIM, DMARC, BIMI) for marketing domains to identify policy gaps exposing campaigns to spoofing, rejection, or inbox displacement.
Audits domain email deliverability (SPF, DKIM, DMARC, MX records, blacklists, TLS), generates 0-100 health score with prioritized fixes, checks bulk sender compliance, provides DNS updates.
Hunts subdomain takeover vulnerabilities using DNS CNAME analysis, HTTP error fingerprints, and modern provider-specific checks (Azure, Zendesk, Vercel, Fastly, S3). Emphasizes account-takeover chain primitives for report writing.