Skip to content
KitploitKITPLOIT
FerramentasBlog
Enviar
FerramentasBlog
Enviar

Ferramentas de Hacking, PenTest e Cibersegurança para o seu Arsenal de Segurança!

Kitploit é um diretório de ferramentas de hacking, cibersegurança e pentesting. Descubra as últimas atualizações de projetos para encontrar vulnerabilidades, analisar sistemas, automatizar testes e fortalecer sua segurança.

··Feeds·Contato·Privacidade·© 2026 Kitploit

Diretório de Ferramentas

Categorias

Ver todas as categorias
Loading categories
cuddlephish — Browser-in-the-Middle (BitM) Armado para Testadores de Penetração | Kitploit
Ferramentas/GitHubGitHub/fkasler/cuddlephish
Ferramentas de PhishingExploração de Aplicações WebPhishingTestes de PenetraçãoEngenharia SocialRed Teaming
GitHubfkasler/cuddlephish

cuddlephish

Browser-in-the-Middle (BitM) Armado para Testadores de Penetração

Ver Repositório
67380há 4 mesesRevisado pelo Kitploit

Mais Populares

Ver todos →

Descubra as ferramentas mais usadas pela nossa comunidade.

Explore todas as ferramentas

Navegue pela nossa coleção de ferramentas

Ver todas as ferramentas →
Compartilhar

CuddlePhish

phishy

Navegador-no-meio (BitM) multi-usuário armado para testadores de penetração. Este ataque pode ser usado para contornar a autenticação multifator em muitas aplicações web de alto valor. Funciona até mesmo para aplicações que não utilizam tokens de sessão e, portanto, não seriam exploráveis usando ataques tradicionais de roubo de tokens. Esta é uma ferramenta de engenharia social e não explora nenhuma falha técnica no serviço alvo.

Início Rápido

Esta ferramenta é um servidor web especializado. Foi projetada para ser executada em um servidor Linux Debian 11 (Bullseye) e depende de informações de IP público para proteger a funcionalidade de administração. Não espere conseguir testar localmente sem enfrentar grandes dificuldades.

Aviso: Chromium não é suportado em ARM. Embora seja tecnicamente possível forçar o uso de um binário Chromium ARM, você perderá todos os recursos/proteções adicionais do puppeteer-extra.

Esta configuração de exemplo utiliza o Caddy para lidar com TLS, SNI e adicionar alguns cabeçalhos personalizados, como 'X-Real-IP', a cada requisição. Você não precisa usar o Caddy com o Cuddlephish, pois o mesmo proxy reverso pode ser configurado usando Nginx, Apache, etc. Eu gosto do Caddy porque é fácil de instalar com Docker e tem plugins para gerenciar certificados Letsencrypt para a maioria dos registradores de domínio. O Caddyfile de exemplo mostra como configurá-lo para Gandi. Consulte a documentação do seu registrador.

Instale Docker, Node, XVFB e algumas outras dependências:

root@kitploit:~
git clone https://github.com/fkasler/cuddlephish
cd cuddlephish
sudo bash install_deps.sh

Você pode então usar o Docker para construir o Caddy com um plugin de certificado curinga para seu registrador. O exemplo é para Gandi. Consulte a documentação aqui e a lista de módulos de provedores DNS aqui. Você pode modificar o Dockerfile para seu registrador antes de construir:

root@kitploit:~
sudo docker build -t caddy .

Agora modifique o Caddyfile para trocar seu domínio e a chave de API do Gandi (ou outro registrador) e inicie o Caddy. Recomendo iniciar isso em uma janela screen ou tmux para que você possa executar o servidor Node em outra janela em breve:

root@kitploit:~
sudo docker run -p 80:80 -p 443:443 -p 2019:2019 -v $PWD/Caddyfile:/etc/caddy/Caddyfile --network=host caddy:latest

Com o Caddy lidando com o tráfego para nós nas portas 80 e 443, podemos finalmente executar a ferramenta!

Instale as dependências do Node:

root@kitploit:~
npm install

Alguns ajustes de configuração: PASSO CRÍTICO: Certifique-se de modificar o config.json de exemplo para adicionar seu(s) IP(s) público(s) aprovado(s) para acesso de administrador. Essa lista de permissões de IPs é o que dita o acesso à interface web "/admin". Você também deve alterar a chave de socket padrão para algo mais seguro.

A ferramenta não está configurada para atacar nenhum login por padrão, então você precisará adicionar alguns. Há um script 'add_target.js' para facilitar essa etapa. Basta executar o script e colar a URL do portal de login que você deseja segmentar quando solicitado:

root@kitploit:~
node add_target.js

Isso capturará o nome do serviço, o título da aba e o favicon para você e adicionará uma entrada em 'targets.json'. Você pode executar este script várias vezes e ele adicionará seus novos alvos. O script nomeará cada serviço com base no domínio, sem o nível superior. Então, para 'https://www.example.com/login.php', o serviço seria apenas 'example' ao especificar seu alvo quando você...

Execute-o!

root@kitploit:~
node index.js example

Após alguns segundos, você deve ver uma mensagem no console quando sua primeira instância automatizada do Chrome fizer check-in via websockets. Agora, os visitantes do seu site de phishing devem ver o que parece ser a página de login alvo, mas na verdade é um feed de vídeo da sua instância automatizada do navegador. Eles também podem interagir com sua instância do navegador e fazer login para você.

Se você configurou corretamente seu(s) IP(s) de administrador no config.json, você deve conseguir visualizar uma interface web especial '/admin' para rastrear usuários, visualizar logs de teclas, assumir o controle de instâncias do navegador logadas, roubar cookies e excluir instâncias indesejadas do navegador.

Nota: Você não verá nada na página de administração até ter algumas vítimas. Assim que tiver uma vítima, a instância do navegador dela deve aparecer na UI de administração.

Solução de Problemas ("Apenas vejo uma página em branco")

Várias pessoas abriram issues sobre uma "Página Branca em Branco", que é mais um sintoma de muitos problemas possíveis, e não um problema em si. Por favor, não abra issues com nomes de sintomas vagos. Em vez disso, se você tiver uma página em branco no lado do usuário, tente primeiro verificar o seguinte:

  • Verifique se o título da aba do serviço alvo não contém caracteres especiais. Usamos "--auto-select-desktop-capture-source" para dizer ao nosso navegador automatizado qual aba transmitir. Esta opção falha para títulos com caracteres especiais. No entanto, você não precisa que o título completo da aba corresponda; apenas precisa de uma substring suficiente para uma correspondência única.
  • Na mesma linha, se seu serviço alvo envia um redirecionamento 302 ou similar para seu navegador automatizado, e o título da aba muda antes de iniciarmos a transmissão WebRTC para uma vítima, então "--auto-select-desktop-capture-source" falhará. Você pode ver como o add_target.js captura essa informação e replicá-la no index.js junto com uma instrução console.log() para ver se o título mudou antes de negociar o WebRTC.
  • Verifique se o HTML do cuddlephish está carregando e se não há erros óbvios de JavaScript no console do desenvolvedor no front-end. A configuração de exemplo do Caddy tem alguns bloqueios básicos em strings de user agent como curl. No mínimo, você deve ver que o título da aba e o favicon estão sendo falsificados.
  • Certifique-se de que você pode interagir com o serviço e porta STUN de exemplo (stun.l.google.com:19302) a partir do seu servidor.
  • Certifique-se de que a rede a partir da qual você está trabalhando permite STUN. STUN só funciona com "NAT de cone completo", "NAT de cone restrito (endereço)" e "NAT de cone restrito a porta". NÃO funciona com "NAT simétrico".
  • Certifique-se de que você pode interagir com o serviço e porta STUN de exemplo (stun.l.google.com:19302) a partir do navegador da vítima de teste. Tente usar https://icetest.info/.
  • Se sua rede não conseguir alcançar o servidor STUN de exemplo, mude para um que você consiga alcançar. Se sua rede não permite STUN, então existe uma configuração de exemplo para um servidor TURN nas páginas HTML cuddlephish e broadcast. Você terá que configurar ou pagar pelo seu próprio servidor TURN. NOTA: Um servidor TURN tem a maior chance de conectar vítimas de phishing às suas instâncias do navegador.

Em um nível alto, se você apenas vê uma página em branco no front-end, isso significa que há alguma quebra ocorrendo na cadeia de fluxo de dados desde "Iniciar WebRTC" > "Selecionar Aba para Transmitir" > "Negociar ICE com o Navegador da Vítima" > "Transmitir Vídeo". As etapas de solução de problemas acima visam ajudá-lo a seguir os dados através desse processo. Quando funcionando corretamente, você deve esperar ver um fluxo de log no servidor semelhante ao seguinte:

troubleshoot

Espero que isso ajude com quaisquer problemas e, como sempre, informações suficientes para reproduzir consistentemente um problema são um pré-requisito para abrir issues para investigação adicional.

Recursos de Administração

Enviar Payload:

Dispara manualmente um payload para download no sistema da vítima via JavaScript. Cada alvo começa com 'payload.txt' como payload de teste. Basta trocar a localização do arquivo em targets.json para enviar um payload personalizado.

Expulsar Usuário:

Envia uma mudança de window.location para a vítima, redirecionando-a para o portal de login real. Parecerá que ela está sendo forçada a reautenticar e impedirá que ela veja você assumir o controle. Se você modificar o código, poderá fazer outras coisas interessantes com essa técnica geral ;)

Assumir Controle:

Permite que você entre e assuma o controle de uma instância do navegador diretamente do portal de administração. Para parar de controlar a instância, pressione a tecla ESCAPE. Nota: Isso tirará o controle da vítima de phishing e ela poderá ver seus movimentos se você não a expulsar primeiro. Você foi avisado.

Devolver Controle:

Permite que você devolva manualmente o controle da instância automatizada do navegador ao usuário. Isso pode ser útil para alguns cenários de engenharia social ao fingir ser TI. Você pode dizer ao usuário que está iniciando uma sessão de ajuda, assumir o controle e navegar até o serviço alvo, devolver o controle e fazer com que ele faça login, assumir o controle novamente, etc.

Obter Cookies:

Extrai todos os itens de cookie e armazenamento local da instância do navegador e baixa como um arquivo JSON. Para injetar esse material de credenciais de volta em uma instância do navegador em execução em seu sistema local, há um script no projeto chamado 'stealer.js'. Ele deve ser executado a partir da sua máquina, e não do servidor, então para usá-lo, você também precisará instalar os componentes Node do projeto em seu sistema.

root@kitploit:~
node stealer.js ~/Downloads/cuddle_asdf1234.json

Remover Instância:

Mata uma instância do navegador quando você não precisa mais dela. Às vezes, os usuários não fazem login completo para você. Às vezes, a conexão WebRTC falha. Às vezes, uma sessão expira antes que você possa usá-la. Nesses casos, este botão pode ajudá-lo a limpar instâncias de navegador inúteis através do portal de administração.

Uma nota sobre keylogs e dados do usuário:

Cada navegador é gerado com seu próprio "id do navegador" aleatório e diretório de dados do usuário correspondente na pasta "user_data" do projeto. Em alguns casos em que 'stealer.js' não está funcionando, você pode precisar replicar os dados do usuário para aquela instância também. Isso pode ser útil em casos que visam serviços com um recurso "lembrar deste navegador", dependendo de como esse recurso é implementado.

Há também um keylog.txt em cada diretório de dados do usuário com um keylog completo do usuário vítima. O keylog geral no portal de administração tenta levar em conta coisas como backspaces, enquanto este keylog.txt terá todas as teclas registradas.

Integração Phishmonger

Exemplo pm.json:

root@kitploit:~
{
  "tacking_id": "id",
  "logging_endpoint": "https://www.phishmongerserver.com/create_event",
  "admin_cookie": "admin_cookie=s3cret",
  "post_url_search": "ppsecure"
}

Por baixo dos panos

Esta ferramenta funciona pareando visitantes do site de phishing com um navegador Chrome automatizado, executado no servidor de phishing. Um feed de vídeo da instância do Chrome controlada pelo atacante é então transmitido para a vítima de phishing via WebRTC, e todos os movimentos do mouse e pressionamentos de teclas fornecidos pelo usuário são encaminhados do navegador da vítima para sua instância associada do Chrome. O servidor usa websockets para rastrear vítimas, pareá-las com navegadores, intermediar feeds de vídeo WebRTC e fazer homem-no-meio nas entradas do usuário. Para cada novo visitante, o servidor gera uma nova instância do Chrome. Como estamos usando o Chrome Devtools Protocol (CDP) para controlar cada instância do Chrome, podemos usar APIs como "Storage.getCookie" para extrair cookies de sessão para sites alvo depois que o usuário fizer login para nós. Também podemos intervir a qualquer momento e controlar diretamente cada instância do Chrome, aproveitando o mesmo método que usamos para dar controle remoto às vítimas em primeiro lugar.

O Servidor Node Realiza o Seguinte:

  • Inicia um novo navegador ("phishbowl vazio") com uma instância xvfb como tela virtual e navega uma aba para a página de login alvo
  • Carrega uma página web personalizada, broadcast.html, com script de configuração WebRTC em uma nova aba no navegador automatizado
  • O navegador faz check-in via websockets
  • A vítima visita o site e faz check-in via websockets
  • Pareia a vítima com o navegador, intermedia o stream de vídeo WebRTC via websockets e gera um novo navegador para a próxima vítima
  • Os navegadores são rastreados por um ID aleatório para permitir que administradores "assumam o controle" de uma instância do navegador ou extraiam material de credenciais de uma instância.

Perguntas e Respostas

Por que você lançaria algo tão perigoso? (AKA, aquela pergunta que minha mãe me faz toda vez que falo na Black Hat)

Pelo meu entendimento, essa técnica tem sido teorizada e até mesmo armada há vários anos (veja os agradecimentos). Então, embora atores de ameaças possam aproveitar essa técnica, e provavelmente já o fazem há algum tempo, profissionais de segurança ofensiva não tiveram uma maneira fácil de replicar essa técnica e podem até desconhecer sua existência. Minha intenção ao lançar a ferramenta é permitir que testadores de penetração e red teamers usem o BitM em operações para mostrar seu impacto potencial e ajudar os defensores de rede a se prepararem para ameaças reais.

Como posso defender meu serviço desse tipo de ataque?

Primeiro, entenda que este ataque depende de enganar um usuário para visitar um site malicioso. A lista de permissões de domínio ajudaria muito a prevenir este e outros tipos de engenharia social. Se confiarmos que os usuários gerenciem 100% dos dados de credenciais (senha, OTP, SMS, PhoneFactor, notificação push, etc.) para um serviço web, então estamos potencialmente vulneráveis a este ataque. Portanto, para frustrar este ataque, precisamos aproveitar dados de credenciais que os usuários não gerenciam. Por exemplo, certificados TLS do cliente podem ser emitidos para dispositivos cliente e só serão válidos para o serviço web real. O certificado é gerenciado pelo navegador e sistema operacional, e não há como o servidor do atacante obter uma cópia do certificado TLS da vítima. Outra opção é usar U2F ou FIDO2 com hardware como um YubiKey para gerenciar parte dos dados de credenciais necessários. Não há como um site hacker interagir com um YubiKey conectado ao computador da vítima.

Você usa Docker para o Caddy, mas não para o servidor Node. Por quê?

Não sou um expert em Docker (ainda). Se você conseguir criar uma configuração simples com Docker, eu adoraria um pull request.

Qual é a história do nome bobo?

É um trocadilho com Cuttlefish (sépia), uma criatura marinha foda que pode se camuflar no ambiente, Phishing, porque requer engenharia social para realizar o ataque, e intencionalmente escrito errado para ser único, divertido e bobo. Me deixa feliz pensar que esse nome de ferramenta engraçado será mencionado junto com achados de risco crítico em relatórios de pentest.

Agradecimentos

Embora eu tenha desenvolvido esta técnica e implementação de forma independente, desde então soube que alguns outros pesquisadores me antecederam na descoberta. Cada um deles adotou uma abordagem usando clientes VNC baseados na web para alcançar um resultado semelhante. É uma abordagem intuitiva e pode ser aplicável para realizar ataques MitM contra outros softwares, não apenas navegadores (VPN-no-navegador talvez?). Definitivamente vale a pena conferir:

Franco Tommasi, Christian Catalano & Ivan Taurino https://link.springer.com/article/10.1007/s10207-021-00548-5

@mrd0x https://mrd0x.com/bypass-2fa-using-novnc/

Também:

Agradecimento a Daniel Aaron @majordmg por ajudar nos estágios iniciais da prova de conceito do WebRTC.

Muito obrigado a RJ Stallkamp @Z3rO-C00L por corrigir e estilizar a interface de administração, e pelo novo logotipo maneiro.

Baixar ferramenta