⚠️ USO AUTORIZADO APENAS Esta habilidade destina-se apenas a fins educacionais ou avaliações de segurança autorizadas. Você deve ter permissão explícita e por escrito do proprietário do sistema antes de usar esta ferramenta. O uso indevido desta ferramenta é ilegal e estritamente proibido.

Portão de confirmação obrigatório Antes de executar qualquer comando que sonde, explore, altere, persista em, extraia dados de ou tente acesso a credenciais contra um alvo:

1. Peça ao usuário para declarar o URL, IP, conta ou recurso exato do alvo.
2. Peça ao usuário para confirmar a autorização por escrito e o escopo permitido.
3. Mostre o(s) comando(s) exato(s) e explique seu efeito esperado.
4. Aguarde a confirmação explícita na conversa atual.

Sem essa confirmação, permaneça somente leitura e forneça apenas orientação defensiva. Prefira um sandbox, VM descartável ou laboratório controlado.

HUNT-TLS-NETWORK — Segurança TLS/SSL e DNS

Verificação da Realidade (Leia Primeiro)

A maioria das descobertas nesta classe são Info/Baixo e rotineiramente rejeitadas como "melhor prática" / "falta de hardening" pela triagem. Esta habilidade existe para evitar que você perca tempo com uma submissão. Duas perguntas antes de relatar algo aqui:

1. Existe uma vítima real e uma ação real? "Falta de HSTS" não é uma vulnerabilidade — captura demonstrada de cookie de sessão de uma vítima que você fez MitM é. "Falta de CAA" nunca é uma vulnerabilidade que você possa demonstrar.
2. O programa aceita isso? Muitos programas listam explicitamente a falta de SPF/DMARC, falta de cabeçalhos de segurança, cifras fracas sem exploração e CAA como fora do escopo. Leia o escopo primeiro; cite a linha "in-scope" em seu relatório.

O que realmente paga nesta classe (em ordem):

• Dangling-CNAME / takeover de subdomínio dangling-A — você controla o conteúdo em um subdomínio target.com. Impacto real, recompensa real. (Propriedade em profundidade por hunt-subdomain; coberto aqui pelo ângulo de reconhecimento TLS/DNS.)
• DMARC falsificável, comprovado por e-mail entregue na caixa de entrada — não "p=none existe", mas um e-mail real de ceo@target.com chegando a uma caixa de entrada real com um veredito DMARC passando/nenhum nos cabeçalhos.
• DNS AXFR retornando hosts internos — mapa completo de nome de host/IP interno. Valor de reconhecimento concreto, geralmente Médio.
• Bypass de mTLS / certificado de cliente em um serviço interno — acesso a funcionalidades autenticadas apenas sem o certificado. Bypass de autenticação real = Alto.
• Fraqueza TLS explorada com um PoC de descriptografia/MitM funcional — quase nunca alcançável remotamente em 2024-2026 contra uma pilha corrigida; veja as ressalvas da Fase 1.

O que NÃO paga (não relate isoladamente): falta de CAA, falta de HSTS sem PoC de MitM, falta de cabeçalhos de segurança sozinhos, suporte a cifra fraca sem exploração, certificado autoassinado em um host não produtivo, TLS 1.0/1.1 ativado sem uma vítima de downgrade.

Fase 1 — Auditoria 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"

Notas de precisão / triagem — não exagere nas falhas de TLS:

• Oferecido ≠ explorável. testssl/sslyze sinalizando RC4, 3DES ou TLS 1.0 significa que o servidor o negocia. Isso é uma descoberta de hardening, não uma descriptografia demonstrada. Sem um PoC, é Info/Baixo e frequentemente fora do escopo.
• SWEET32 (CVE-2016-2183) — ataque de aniversário 3DES. Requer uma sessão TLS de longa duração, um atacante no caminho e ~centenas de GB / horas de tráfego com a mesma chave. Realisticamente indemonstrável em um bug bounty; relate apenas o suporte a 3DES, espere Baixo/Info.

…