⚠️ USO AUTORIZADO APENAS Esta habilidade é apenas para 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.

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

1. Peça ao usuário para declarar o URL exato do alvo, IP, conta ou recurso.
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 apenas em modo de leitura e forneça orientação defensiva. Prefira um sandbox, VM descartável ou laboratório controlado.

HUNT-WEBSOCKET — Segurança de WebSocket

Alvos de Joia da Coroa

CSWSH (Cross-Site WebSocket Hijacking) com um handshake autenticado por cookie e sem token CSRF/por conexão = Alto–Crítico (exfiltração em tempo real de dados de qualquer vítima logada).

Cadeias de maior valor:

• CSWSH → exfiltração de dados / ATO — o handshake autentica via cookie ambiente, sem token CSRF, Origin não aplicado → a página do atacante abre o WS como a vítima e transmite suas mensagens/PII/tokens. Se o stream carregar um token de sessão/atualização/CSRF, isso escala para ATO.
• Sem autenticação por mensagem — autenticação HTTP/handshake presente, mas quadros WS individuais não são reautorizados → mensagens privilegiadas aceitas (deleteUser, getSecretConfig).
• Adulteração de mensagens — modificar quadros em trânsito (preço, quantidade, userId, valor) em aplicativos de negociação/jogos/checkout → fraude financeira.
• Bypass de autorização de namespace / sala do socket.io — conectar-se a um namespace privilegiado ou entrar na sala de outro usuário sem uma verificação de permissão → exfiltração em tempo real entre inquilinos.
• Tunneling de falsificação de Upgrade na camada de handshake — um handshake Upgrade/Connection/Sec-WebSocket-* malformado faz com que o proxy frontal e a origem discordem sobre se uma atualização ocorreu → túnel de falsificação de solicitação.

Fundamentação — Casos de Referência (leia antes de caçar)

Estas são referências públicas e verificáveis. Use-as para calibrar como é uma descoberta de WS real e como ela foi comprovada. Não invente IDs de relatório ou pagamentos adicionais.

Apenas os quatro CVEs acima são afirmados com IDs exatos porque são verificáveis. Para qualquer caso em que você não tenha certeza do identificador exato, descreva a técnica sem citação — um CVE incorreto é pior do que nenhum.

Fase 1 — Descobrir Endpoints WebSocket

# Grep JS para conexões WS (URLs de handshake, clientes socket.io)
grep -rE "new WebSocket|io\(|io\.connect|socket\.io|new SockJS|signalr|Phoenix\.Socket|wss?://" \
  recon/$TARGET/ --include="*.js" 2>/dev/null | \
  grep -oE "(wss?://[^'\"]+|/[a-zA-Z0-9/_.-]*socket[^'\"]*|/signalr[^'\"]*|/cable\b)" | sort -u

# Rastrear URLs para dicas em tempo real
grep -iE "socket|/ws\b|websocket|stream|realtime|live|chat|events|/cable|/signalr|notifications" \
  recon/$TARGET/urls.txt | sort -u

# Sondar handshake (101 = upgrade suportado)
curl -sI -o /dev/null -w "%{http_code}\n" \

…