O que precisávamos cada vez mais — especialmente à medida que mais dos nossos alvos se tornavam ecossistemas de aplicações de IA, onde texto não confiável flui por agentes, saídas de ferramentas, filas de revisão de administradores e consoles de suporte, e executa JavaScript em lugares onde ninguém está observando — era um único framework que fizesse ambas as coisas: o controle interativo e persistente de pós-exploração de um hook do BeEF, e o butim de callback blind-XSS do tipo fire-and-forget, em um único payload confiável nos navegadores atuais e que se parece com as telas de login reais de hoje.

Então construímos o WRAITH.

Atenção: isto é um trabalho em andamento

Estamos lançando o WRAITH cedo, e de propósito. Preferimos colocá-lo nas mãos das pessoas que realmente vão usá-lo — e ouvir o que quebra — do que segurá-lo até que esteja "pronto".

Isso significa: espere arestas e bugs. Alguns módulos são mais testados em batalha do que outros, o comportamento dos navegadores muda sob nossos pés constantemente (veja as notas sobre o scan de rede abaixo), e as APIs podem mudar entre versões. Se você encontrar algo, por favor abra uma issue — passos de reprodução, navegador + versão e o que você esperava são ouro. PRs são bem-vindos sob os termos de contribuição do projeto.

Início rápido (Docker)

O caminho mais rápido. Você precisa de Docker + Docker Compose.

O setup.sh guia você por tudo:

1. Detecta seu IP público (ou permite que você insira um domínio / host personalizado) para que cada hook e URL de payload sejam cunhados com o seu endereço.
2. Faz você definir um nome de usuário + senha de operador para o login do console.
3. Gera o segredo de assinatura de sessão, grava um .env ignorado pelo git (chmod 600), e compila + inicia o contêiner.
4. Imprime suas URLs ao vivo e um payload XSS pronto para uso no final:

Gerencie com comandos padrão do compose:

As sessões capturadas persistem em ./data/ no host — nunca embutidas na imagem, nunca commitadas (.env e data/ são ignorados pelo git).

O console do operador é protegido por login sempre que uma senha de operador é definida, com um login de nome de usuário + senha:

Executar localmente sem Docker (dev)

Em seguida, abra o console do operador em http://127.0.0.1:3000/operator/ e a página de vítima demo em http://127.0.0.1:3000/demo/ (em um segundo navegador/perfil). No localhost, o login é desabilitado por padrão por conveniência — o servidor se recusa a vincular a uma interface pública sem uma senha de operador, para que você não possa expor acidentalmente um painel aberto.

Recursos

Hook + console do operador

/hook.js é um payload pequeno. Coloque-o em qualquer página que você controla (<script src="/hook.js"></script>) ou entregue-o via um XSS no seu alvo. O navegador que o carrega abre um WebSocket de volta para o operador, faz fingerprint de si mesmo (navegador, SO, IP, página, UA), reconecta automaticamente e sobrevive à navegação. Todo navegador com hook aparece ao vivo no console, onde você escolhe um e o controla — o painel completo é a imagem principal no topo deste README: lista de navegadores com hook, detalhes do alvo, controles de implantação, feed de atividade ao vivo e credenciais capturadas.

Sobreposições de engenharia social

Sobreposições modernizadas de login falso, renderizadas em um shadow DOM isolado para que pareçam pixel-perfeitas em qualquer página host e desfoquem a página atrás delas como um modal real de reautenticação. Inclui LinkedIn, Facebook e Microsoft / Office 365 (fluxo autêntico de duas etapas e-mail → senha).

Teclas ao vivo + credenciais capturadas

Cada caractere que o alvo digita em uma sobreposição é transmitido ao console em tempo real, e as credenciais enviadas caem em Credenciais Capturadas — tudo persistido para que nada seja perdido em atualização ou reinicialização.

Page Capture — o butim blind-XSS

No instante em que um navegador é hookado, o WRAITH dispara automaticamente o Page Capture: exatamente o que um framework blind-XSS captura quando seu payload dispara em algum lugar que você não pode ver — onde disparou (origem + URL + referrer), os cookies da vítima (não-HttpOnly), o DOM completo e uma captura de tela. As falhas são relatadas honestamente, porque elas são a lição: cookies HttpOnly nunca aparecem, e CSP ou tainting de canvas de origem cruzada podem bloquear a captura de tela.

Page Mirror — vá além da captura de tela 🆕

É aqui que o WRAITH vai além das ferramentas que substitui. Quando você acerta um XSS cego ou um hook em uma página, a maioria dos frameworks para em uma captura de tela e um despejo de HTML bruto — você pode ver onde seu payload disparou, mas não pode realmente fazer nada com ele.

O Page Mirror do WRAITH transforma esse butim sem saída em uma visão ao vivo e navegável do aplicativo. Abra a página hookada como uma visão real e renderizada de navegador dentro do console do operador — depois clique em links e navegue pelo aplicativo visualmente, exatamente como a vítima faria.

O ponto-chave: cada navegação é buscada através do navegador hookado, então ela viaja na sessão da vítima e na confiança de mesma origem. Qualquer página, endpoint ou recurso que a sessão da vítima possa alcançar, você também pode alcançar — incluindo páginas protegidas por um cookie de sessão autenticada que você nunca vê (e, sendo HttpOnly, nunca poderia roubar diretamente).

No exemplo abaixo, começamos na fila de tickets de um agente de suporte e clicamos direto até um Credential Vault interno — uma página que só resolve dentro de uma sessão autenticada de agente. Nenhuma credencial foi phishingada, nenhum cookie roubado: simplesmente viajamos na sessão da vítima até ela.

Leituras de origem cruzada ainda falham por design (a Same-Origin Policy se mantém) — o alcance do mirror é exatamente o alcance da vítima, nem mais, nem menos. Esse limite é em si parte da lição.

Catálogo de payloads blind-XSS

Um catálogo estilo XSS-Hunter de strings de injeção prontas para disparar para cada contexto (HTML, quebra de atributo, fechamento de tag, manipuladores de eventos, contexto JS, URIs javascript:, jQuery), cada uma preenchida automaticamente com sua URL de hook e copiável com um clique.

Scan de rede local / localhost

Usa o navegador hookado como proxy para fazer fingerprint dos serviços locais da vítima. É um canal lateral de tempo, reconstruído para navegadores atuais — o padrão confiável é um scan calibrado de 127.0.0.1 usando dois primitivos independentes (timing de fetch e WebSocket, o método literal check.js do eBay). Os modos LAN estão incluídos, mas rotulados honestamente, porque o Chrome 142+ Local Network Access agora os bloqueia (veja abaixo).

Laboratório de prática integrado

Um "help desk" deliberadamente vulnerável em /lab com um sink de XSS armazenado, para que você possa demonstrar toda a cadeia de ponta a ponta, mesma origem: envie um ticket malicioso → um "agente" revisa a fila e o payload dispara (o momento blind-XSS) → faça Page Mirror do agente hookado e puxe o vault protegido por sessão. Intencionalmente inseguro por design, com flags plantadas.

Ensinando blind XSS nesta plataforma

O hook dispara no momento em que carrega, exatamente como um payload blind-XSS colocado em um campo armazenado que depois é renderizado em algum contexto de admin/suporte/log/agente que você não pode ver. Lições surgem direto nos dados:

• Cookies são legíveis apenas por JS. Cookies HttpOnly nunca aparecem, que é o objetivo do HttpOnly — e exatamente por isso a abordagem viajar na sessão do Page Mirror importa mais do que roubar o cookie.
• Capturas de tela são best-effort. O html2canvas pode ser bloqueado por CSP, e imagens de origem cruzada contaminam o canvas para que ele não possa ser exportado. Essas falhas são relatadas honestamente em vez de escondidas.
• Origem + referrer dizem onde você pousou, que para blind XSS é a questão inteira ("onde meu payload executou?").

Para um laboratório offline, faça self-host do html2canvas — veja public/vendor/README.md.

Sobre o scan de rede (leia antes de demonstrá-lo)

JavaScript não pode ler respostas de origem cruzada, mas pode iniciar uma solicitação e observar como ela falha e quão rápido, o que vaza o estado da porta. O módulo foi reconstruído em torno do que funciona em navegadores atuais (2025–2026), porque o antigo sweep de LAN da era BeEF agora está morto.

A realidade moderna: o Chrome 142+ (out 2025) lançou o Local Network Access (LNA), que bloqueia solicitações a faixas privadas (10.x / 172.16.x / 192.168.x) atrás de um prompt de permissão. Um sweep de LAN cego não alcança mais o fio. Mas loopback (127.0.0.1) ainda é alcançável, e escaneá-lo é o ataque do mundo real — eBay, Best Buy e outros foram pegos fazendo port-scan do localhost dos visitantes para fazer fingerprint de serviços locais e ferramentas de acesso remoto.

Então o módulo tem três modos:

• Esta máquina (localhost) — o padrão confiável. Um scan calibrado de 127.0.0.1 que testa cada porta com timing de fetch e timing de WebSocket, primeiro aprende a linha de base RST desta máquina, depois sinaliza qualquer coisa que resolva, trave ou rode mais devagar como ABERTA, rotula o provável serviço e mostra se fetch, ws ou ambos concordaram. Funciona no Chrome e no Firefox hoje.
• Host LAN — escaneie um IP privado. Funciona apenas se o navegador permitir; o Chrome 142+ geralmente bloqueará (o módulo detecta isso e avisa).
• Descobrir hosts LAN — sweep de sub-rede. Principalmente bloqueado por LNA agora; mantido para mostrar o bloqueio como a lição.

Como isso se mapeia para o BeEF (para a palestra)

"Como isso é diferente de blind XSS, Evilginx ou EvilGoPhish?"

Essas ferramentas vivem em estágios diferentes do ataque e abusam de contextos de confiança diferentes. Elas são complementares e se encadeiam.

A distinção honesta para ensinar: nosso phish de sobreposição coleta o que o usuário digita — ele não captura uma sessão real nem vence MFA. É exatamente por isso que é um ótimo contraste, e por que a indústria migrou para autenticação resistente a phishing, vinculada à origem (FIDO2 / WebAuthn / passkeys). Uma kill chain realista usa todos os três: blind XSS encontra e entrega execução de código, um hook do WRAITH dá controle interativo dentro da sessão (e, via Page Mirror, alcança funcionalidades do aplicativo diretamente), e um redirecionamento pode canalizar a vítima para um fluxo Evilginx para uma sessão real com MFA aprovado.

Configuração

Tudo é orientado por env; o mesmo build roda em qualquer lugar porque o hook.js deriva sua URL de callback de onde quer que seja servido. O setup.sh grava estes em .env.

Um cookie de sessão HttpOnly assinado cobre tanto o painel quanto o WebSocket ao vivo. O payload de hook, a página demo e o canal /ws/hook permanecem públicos para que as vítimas possam alcançá-los. Como fail-safe, o servidor se recusa a vincular a uma interface pública a menos que uma senha seja definida.

Para uma implantação bare-metal / systemd em vez de Docker, veja deploy/DEPLOY.md.

Arquivos

Licença & atribuição

O WRAITH é © 2026 Arcanum Information Security, lançado sob a Apache License 2.0.

Você é livre para usar, modificar e redistribuí-lo — inclusive em seu próprio treinamento — mas deve manter a atribuição: retenha os arquivos LICENSE e NOTICE e o aviso de direitos autorais da Arcanum em qualquer coisa que você distribuir ou fizer fork, e declare quaisquer alterações que você fez (Apache-2.0 §4). Veja NOTICE. A licença não concede o uso do nome ou das marcas da Arcanum além de descrever de onde o código veio.

Construído com ❤️ pela Arcanum — https://arcanum-sec.com