rcekit

Kit de detecção e confirmação de RCE que testa URLs ou requisições HTTP capturadas em busca de injeção de comandos, SSTI, caminhos cegos e OOB, retornando veredictos em camadas com provas.

Cada linha é reproduzida por tests/bench/, que executa o RCEKit contra essas builds sob Docker e verifica o veredito e seu controle negativo. Última execução verde em 2.36.0 (2026-09-20): 3/3 casos. Essa é uma afirmação pontual, não contínua -- o benchmark é executado em uma cadência, não a cada alteração.

Cada controle é o teste real da linha. Struts2 sondado com reflected retorna negative, porque S2-001 reavalia OGNL e não há shell por trás dele. O sinal time do Webmin é mantido em needs-review em um alvo onde ele por acaso está correto. E o Solr sondado com oob retorna negative embora seja explorável -- oob constrói comandos de shell e um sink ${jndi:...} não executa nenhum deles, que é a lacuna que lookup existe para fechar, medida em vez de afirmada.

A linha do Log4Shell diz lookup-sink, não confirmed: o que o callback prova é que o sink resolveu uma URI escolhida pelo RCEKit. Alcançar RCE requer um servidor que responda à consulta com uma classe carregável, e no nível de risco padrão apenas jndi:dns:// sai -- uma consulta de nome, sem conexão além dela para tal servidor responder.

Início rápido

O RCEKit tem duas formas suportadas, e nenhuma é um substituto da outra.

Instale-o — pipx mantém a CLI em seu próprio ambiente, que é o que você quer para uma ferramenta em vez de uma biblioteca:```bash pipx install rcekit # or: pip install rcekit rcekit --doctor # confirms the corpus it will run with

Ambos executam o mesmo código e reportam os mesmos veredictos. Trabalhar a partir de um checkout é a terceira forma, e também não requer instalação:```bash git clone https://github.com/kabiri-labs/rcekit.git cd rcekit # Python 3.8+, standard library only

| -s | --server | SERVER | http://localhost:8080 | URL do servidor | | -t | --token | TOKEN | null | Token de autenticação | | -u | --username | USERNAME | null | Nome de usuário para autenticação | | -p | --password | PASSWORD | null | Senha para autenticação | | -k | --insecure | INSECURE | false | Ignorar verificação de certificado TLS | | -c | --config | CONFIG | null | Caminho para o arquivo de configuração | | -v | --verbose | VERBOSE | false | Ativar saída detalhada | | -d | --debug | DEBUG | false | Ativar saída de depuração | | -h | --help | HELP | false | Exibir mensagem de ajuda | | -V | --version | VERSION | false | Exibir informações da versão |``` [detect] methods: reflected, eval [detect] sent 13 probes: confirmed=4, negative=9

[detect] CONFIRMED execution (4): [reflected/unix/raw] ; echo RKYZRIP$((540141+314681))RKFWVFS$(echo RKBWOOC)RKYZRIP (target computed 'RKYZRIP854822RKFWVFSRKBWOOCRKYZRIP' — random operands, absent from control)

• --no-verify — Pula a verificação de integridade do arquivo de saída.
• --no-cleanup — Mantém os arquivos temporários após a conclusão.
• --verbose — Ativa a saída de log detalhada.
• --quiet — Suprime toda a saída, exceto erros.

Exemplos

Como Funciona

A ferramenta segue um fluxo de verificação em várias etapas:

1. Descoberta — Identifica o endpoint de destino e confirma a acessibilidade.
2. Preparação — Cria um arquivo de teste com conteúdo controlado.
3. Envio — Envia o arquivo através do mecanismo de upload vulnerável.
4. Verificação — Recupera o arquivo enviado e compara os hashes.
5. Relatório — Gera um relatório estruturado com os resultados.

Aviso Legal

Esta ferramenta destina-se apenas a testes de segurança autorizados e pesquisa educacional. O uso não autorizado contra sistemas sem consentimento explícito por escrito é ilegal e antiético. Os autores não se responsabilizam por qualquer uso indevido ou dano causado por esta ferramenta.

Sempre obtenha a devida autorização antes de testar qualquer sistema.``` [detect] sent 4 probes: confirmed=3, negative=1

[detect] CONFIRMED execution (3): [reflected/unix/raw] ; echo RKHWNHK$((114157+752773))RKXGFIH$(echo RKHSEIF)RKHWNHK (target computed 'RKHWNHK866930RKXGFIHRKHSEIFRKHWNHK' — random operands, absent from control)

| -s | --server | SERVER | http://localhost:8080 | URL base do servidor | | -t | --token | TOKEN | | Token de autenticação | | -k | --insecure | | false | Ignorar erros de TLS | | -o | --output | FORMAT | text | Formato de saída (text, json) | | -v | --verbose | | false | Ativar registro detalhado | | -q | --quiet | | false | Suprimir saída não essencial | | -c | --config | FILE | ~/.config/tool/config.yaml | Caminho do arquivo de configuração | | -n | --dry-run | | false | Simular sem executar ações | | -f | --force | | false | Forçar operação sem confirmação | | -y | --yes | | false | Responder sim a todos os prompts | | -d | --debug | | false | Ativar saída de depuração | | -h | --help | | | Exibir mensagem de ajuda | | -V | --version | | | Exibir informações da versão |

Exemplos

Arquivo de Configuração

O arquivo de configuração usa o formato YAML:

Variáveis de Ambiente

Códigos de Saída

Solução de Problemas

Erro: Conexão recusada

Verifique se o servidor está em execução e se a URL está correta:

Erro: Autenticação falhou

Verifique se o token está correto e não expirou:

Erro: Tempo limite excedido

Aumente o tempo limite ou verifique a conectividade de rede:

Erro: Permissão negada

Execute com privilégios elevados ou verifique as permissões do arquivo:

Contribuindo

Contribuições são bem-vindas! Por favor, siga estas etapas:

1. Faça um fork do repositório
2. Crie uma branch para sua funcionalidade (git checkout -b feature/nova-funcionalidade)
3. Faça commit das suas alterações (git commit -am 'Adiciona nova funcionalidade')
4. Faça push para a branch (git push origin feature/nova-funcionalidade)
5. Abra um Pull Request

Licença

Este projeto está licenciado sob a Licença MIT - consulte o arquivo LICENSE para obter detalhes.

Agradecimentos

• Contribuidor 1
• Contribuidor 2
• Contribuidor 3

Aviso Legal

Esta ferramenta é destinada apenas para testes de segurança autorizados e fins educacionais. Os usuários são responsáveis por garantir que têm permissão para testar os sistemas de destino. Os autores não se responsabilizam por qualquer uso indevido ou danos causados por esta ferramenta.

Contato

• Site: https://example.com
• Twitter: @example
• Email: [email protected]``` [verify] loaded request from search.req: enumerating 4 injection point(s) [detect] enumerating 4 injection point(s) x 3 method(s) [detect] cost: 4 points x ~1739 probes = at least 6964 requests [detect] body param 'q': confirmed (1544 probes) <-- CONFIRMED [detect] sent 6371 probes: confirmed=446, negative=5925

Ele dispara onde quer que uma execução possa silenciosamente se tornar vazia: um método que não se aplica aos ambientes selecionados, um degrau de --sink-shape para o qual o shell escolhido não tem sintaxe, uma seleção de --bridges inteiramente retida pelo teto de segurança, um corpo de requisição que quebrou a entrega antes de chegar.

Uma execução que foi apenas parcialmente cegada recebe o mesmo tratamento um nível abaixo. Se você pediu um oráculo de segunda ordem e o endpoint observado nunca respondeu, os veredictos das sondagens ainda se mantêm — mas a execução informa que eles foram decididos sem nunca ler o canal que você apontou, em vez de deixá-los passar como um negativo de segunda ordem.

O que ele confirma

Uma CLI, uma flag --methods, cobrindo os principais caminhos para RCE:

Três coisas ampliam onde esses métodos podem alcançar, sem mudar o que qualquer um deles chamará de confirmed:

• Execução de segunda ordem (--observe-url) — quando o payload chega em uma requisição e executa em outra: SSTI armazenado renderizado em uma página de perfil, um payload escrito em um log que um motor de template posteriormente renderiza, um job enfileirado. O endpoint observado é diferenciado contra um snapshot tirado antes de qualquer sondagem ser enviada.
• Pontes de linguagem de consulta (--bridges) — COPY … FROM PROGRAM, xp_cmdshell, expect://. Uma ponte é um transportador, não um oráculo: ela envolve o comando que os métodos já constroem, então os mesmos níveis se aplicam através dela.
• Enumeração de pontos de injeção (-p all) — query, folhas JSON, campos de formulário, partes multipart, cookies, cabeçalhos e segmentos de caminho, cada um codificado para onde cai, com o custo da sondagem impresso antes de qualquer disparo. Um corpo GraphQL é ordenado pelo que pode realmente confirmar: as variables que um resolver lê antes do próprio documento de operação.

Combine métodos livremente: --methods reflected,eval,time executa os três e reporta cada nível separadamente.

Escopo honesto. O RCEKit confirma RCE que é alcançável por injeção em uma requisição e interpretado por um shell ou um avaliador. Ele não cobre bugs de corrupção de memória (buffer overflow, UAF) ou injeção de argumentos em um array argv sem shell — esses são problemas diferentes. Cadeias de gadgets de desserialização também ficam fora do escopo: --methods deser prova que um endpoint desserializa dados do atacante e o diz em seu próprio nível, mas qual gadget (se algum) transforma isso em execução depende do classpath do alvo, e o RCEKit não afirma saber. Ele visa ser excelente nas classes de RCE orientadas por injeção acima em vez de medíocre em tudo.

Como o RCEKit se compara

As outras ferramentas neste espaço são construídas para te colocar dentro. O RCEKit é construído para que o achado sobreviva ao escrutínio de outra pessoa — o reteste do cliente, a fila de triagem, a revisão do relatório. Essa diferença aparece três vezes.

1. Um ponto de injeção, todas as classes, uma execução

Você raramente sabe a classe antes de testar. Cobrir um sink desconhecido com ferramentas de classe única significa executar cada uma por vez e reconstruir a requisição para cada uma:

_{Cobertura conforme a lista de técnicas documentadas de cada projeto. SSTImap é o sucessor mantido do tplmap, que seu autor marcou como não mantido.}```bash

Command injection, expression injection and blind timing against the same

parameter, in one pass, with zero infrastructure

python rcekit.py --acknowledge-consent -r request.txt -p host --methods reflected,eval,time

Aqueles dois teriam sido descobertas de outra pessoa. Cinco mecanismos produzem esse veredito, e eles são executados em cada confirmação:

• Uma requisição de controle sem payload. A evidência deve estar presente com o payload e ausente sem ele. Qualquer coisa em ambos é inconclusive, não uma descoberta.
• Um controle inerte com o mesmo token. Uma segunda requisição carrega o token aleatório idêntico em uma forma não executável. Um alvo que meramente ecoa a entrada falha aqui — que é como uma reflexão é separada de uma execução.
• Operandos aleatórios, nunca strings fixas. O oráculo é uma soma envolta em tag ou um produto delimitado por fronteira calculado do zero a cada execução. Ecoar o payload retorna o literal $((a+b)); apenas a execução retorna o valor.
• Busca de evidência ciente de codificação. Um sink que aplica base64, hex, URL, HTML ou unicode-escape à sua saída ainda confirma — o corpo bruto é verificado primeiro, então a decodificação só transforma um acerto perdido em acerto, nunca o contrário.
• Busca de evidência em toda a resposta. O valor computado é procurado em todos os canais da resposta — corpo, cabeçalhos da aplicação, valores de cookie, o alvo de redirecionamento, a frase de razão HTTP, e cada folha de um envelope de erro JSON — e a descoberta nomeia o canal que o carregou. O diferencial de controle é aplicado a todos os canais também, então ampliar onde o RCEKit procura não amplia o que ele chamará de confirmed.

O mesmo instinto funciona no sentido oposto. Timing nunca se autoconfirma, um callback de desserialização nunca é chamado de RCE, e uma execução que não construiu nenhuma sonda nunca é chamada de negativa.

3. É construído para um engajamento autorizado, não para um laboratório

Os controles que as regras de engajamento de um cliente realmente pedem, na ferramenta em vez de nas suas anotações:

Quando recorrer a outra coisa

Quer um shell em vez de um veredito? commix e SSTImap continuam para pós-exploração; o RCEKit para na prova por design. Varrendo milhares de hosts em busca de CVEs conhecidas? Esse é o trabalho do Nuclei — e o RCEKit escreve templates do Nuclei (--output-format nuclei), então ele alimenta o seu scanner em vez de competir com ele. Já sabe que a injeção é SQL e quer o banco de dados em si? sqlmap domina esse terreno — as pontes do RCEKit existem para provar que o SO é alcançável a partir de um parâmetro de texto, não para explorar o banco de dados.

Encontre a sua situação

Cada linha é um exemplo prático no guia de campo — o comando, o que ele envia, e como ler o que volta.

Documentação

Segurança & ética

O RCEKit explora, e esse é o ponto. Uma vulnerabilidade é confirmada fazendo o alvo executar a coisa, porque essa é a única evidência que uma assinatura não pode falsificar e uma build corrigida não pode produzir por acidente. O que limita uma execução não é a relutância em explorar. São dois fatos estruturais e um interruptor.

Ele não aceita nenhum payload arbitrário seu. As sondas são construídas pelo motor para servir a um oráculo — aritmética sobre operandos aleatórios para aquela sonda, um nome que apenas esta execução poderia ter escolhido. Não há entrada que transforme a detecção em outra coisa, porque não há tal entrada a fornecer.

Qualquer coisa que vá além de computar um valor declara o nível que precisa, então uma flag decide até onde uma execução vai: --verify-active-risk safe | intrusive | stateful. Um método ou uma forma de sonda única acima desse nível é retido pelo nome, com a flag que o enviaria — uma escada que encolhe silenciosamente é indistinguível de um alvo sem nada a encontrar. Contra uma instância descartável, eleve o nível e obtenha tudo o que a ferramenta tem.

• Portão de consentimento — geração e verificação de exploração exigem --acknowledge-consent; --detection-only é benigno e não exige.
• Seguro por padrão — a verificação dispara apenas provas de baixo impacto; reverse shells, download-execute, acesso a credenciais, movimento lateral, escape de contêiner, metadados de nuvem e payloads OOB são retidos até você elevar --verify-active-risk. Payloads destrutivos (persistência, backdoors) nunca são disparados sem --verify-allow-destructive. Um plano de execução imprime exatamente o que será enviado antes de qualquer coisa disparar.
• Níveis de segurança — safe / intrusive / stateful. Payloads do corpus são filtrados por --max-safety; métodos de detecção e suas formas de sonda declaram os mesmos degraus e são filtrados por --verify-active-risk, então um método que faz o alvo se comunicar externamente ou deixa algo para trás está sujeito à mesma ordenação que cada payload do corpus. O pré-voo nomeia o nível que cada item retido realmente precisa. file e write são controlados pela sua própria configuração em vez disso: nenhum dos dois faz nada até você nomear um diretório para escrever e uma URL para ler de volta.
• Auditoria & logging — cada execução de exploração/verificação é registrada em exploit_audit.log; --watermark incorpora um token rastreável; logs de execução vão para rcekit.log.
• Integridade do corpus — um corpus corrompido, ou um --template-file explícito que está ausente, faz o RCEKit se recusar a rodar e sair com código diferente de zero em vez de gerar silenciosamente nada (--doctor verifica isso). Apenas um arquivo de corpus padrão ausente recorre à cópia embutida, e ele avisa quando o faz.

Este toolkit destina-se apenas a testes de penetração autorizados, pesquisa de segurança, educação e treinamento defensivo. Nunca o use contra sistemas sem permissão explícita — testes não autorizados são ilegais.

Desenvolvimento```bash

python -m unittest discover -s tests # dependency-free test suite

A suíte de testes falha se os dois divergirem. Consulte CONTRIBUTING.md.

Licença

MIT — consulte LICENSE.