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
XeytanWin32-RAT — TRABALHO EM ANDAMENTO. RAT escrito em C++ usando Win32 API | Kitploit
Ferramentas/GitHubGitHub/melardev/xeytanwin32-rat
Escalada de PrivilégiosMecanismos de PersistênciaExploraçãoMovimento LateralShellcodeExfiltração de DadosPós-ExploraçãoComando e ControleFerramenta de Acesso RemotoDesenvolvimento de PayloadsCavalo de Troia de Acesso Remoto
2010há 6 anosRevisado 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
GitHub
melardev/xeytanwin32-rat

XeytanWin32-RAT

TRABALHO EM ANDAMENTO. RAT escrito em C++ usando Win32 API

Ver RepositórioSite

AVISO

Este é um RAT cheio de bugs, incompleto, instável. Ainda é um aplicativo "work in progress".

Introdução

Projeto criado para matar um pouco do meu tempo livre, não é mantido ativamente. Há muitas coisas a melhorar/corrigir, e levará tempo para atingir estabilidade neste projeto.

Funcionalidades

  • Shell Reverso
  • Listar Processos
  • Streaming da Área de Trabalho
  • Sistema de Arquivos
  • Baixar Arquivo

Entendendo o projeto

IThreadChannels são meios de comunicar duas threads de forma síncrona. Eu os uso como o objeto atômico compartilhado por duas threads para comunicação. Neste aplicativo, quero comunicação bidirecional, então preciso de dois canais; por isso criei o IDoubleThreadChannel. Síncrono significa que eles precisam ser chamados pelas threads que se comunicam para receber eventos conforme necessário. Exemplo: a thread da UI chamará getFromApp() e bloqueará lá para receber eventos do App.

Os comunicadores, por outro lado, gerenciam sua própria thread e disparam callbacks de forma assíncrona. Você não os chama, eles te chamam.

Diretrizes

  • Objetos Packet devem ser deletados pelo NetServerService
  • Ponteiros Client devem ser deletados pela Application.

Macros

  • SHOW_CONSOLE Se um console deve ser mostrado para fins de depuração.
  • MANUAL_MEMORY_MANAGEMENT Se verdadeiro, tento gerenciar a memória que aloco (para aprendizado); se falso, então usarei shared_ptr para tornar o gerenciamento de memória muito mais fácil.

TAREFAS

  • Funcionalidade de streaming da área de trabalho não finalizada (sair do loop infinito).
  • Livre-se de erros, principalmente problemas de conversão.
  • O cabeçalho do pacote deve enviar 8 bytes para o comprimento do pacote, não int32_t, então mude para uint64_t
  • Use Read/Write Locks https://docs.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-acquiresrwlockexclusive
  • O campo dataLength na classe Buffer está incorreto, deve ser melhorado
  • O problema dos objetos Event terem um void* que não deve ser deletado através de delete void* pode ser resolvido como fiz: o consumidor do evento cuida de fazer o cast para o valor esperado e deletá-lo, ou usando templates de classe como new AppEvent e então isso poderia ser delete objeto*
  • A classe Buffer deve lançar exceções em operações ilegais.
  • Criptografia
  • Streaming de Câmera
  • Tratamento de Erros .... em todo lugar.
Baixar ferramenta