material • 21/05/2026

Material introdutório de exploits

Uma aula introdutória sobre busca, análise e uso de exploits em ambientes controlados

por rideckszz

C:\>aula_ □ ×

Exploits

Material introdutório sobre como pesquisar vulnerabilidades conhecidas, encontrar provas de conceito e adaptar exploits em ambientes controlados.

O foco aqui é o caminho até a exploração: enumeração, busca, validação, leitura do código e execução com cuidado.

1. O que é um exploit?
C:\>conceito_ □ ×

Falha → Exploit → Impacto

Um exploit é um código, técnica ou procedimento que aproveita uma vulnerabilidade para produzir um efeito no sistema.

Esse efeito pode ser leitura de arquivos, execução de comandos, acesso indevido, vazamento de dados, alteração de comportamento ou negação de serviço.

Em segurança ofensiva, a vulnerabilidade é a falha. O exploit é a forma prática de acionar essa falha.

Antes de usar uma PoC encontrada na internet, separe três coisas:

Vulnerabilidade

A falha existente no software, serviço, configuração ou lógica da aplicação.

Exploit

O código ou técnica usada para acionar a falha.

Impacto

O que muda depois da exploração: leitura, execução, alteração, acesso ou indisponibilidade.

Regra prática: exploit sem contexto vira chute. Primeiro entenda o alvo, depois procure a PoC.

2. Escopo e autorização
C:\>escopo_ □ ×

Sem autorização, não teste

Exploração só deve ser feita em ambientes autorizados.

Para estudo, use CTFs, laboratórios locais, máquinas vulneráveis criadas para treino e plataformas educacionais.

Este material considera um contexto de aprendizado. Em ambiente real, exploração sem autorização pode causar dano e gerar consequências legais.

Mesmo em auditorias autorizadas, respeite escopo, janela de teste, regras de engajamento e limites combinados.

CTF

Ambiente feito para estudo. A exploração faz parte do desafio.

Lab local

Serviços vulneráveis controlados por você.

Ambiente real

Só com autorização explícita e escopo definido.

3. O que é CVE?
C:\>identificação_ □ ×

Nomeando vulnerabilidades

CVE significa Common Vulnerabilities and Exposures.

É um identificador público usado para catalogar vulnerabilidades conhecidas.

Um CVE serve como referência. Ele ajuda a pesquisar detalhes técnicos, versões afetadas, impacto, mitigação e provas de conceito.

Exemplos de formato:

CVE-2019-9053

CVE

Identificador da vulnerabilidade.

Versões afetadas

Quais versões do software possuem a falha.

PoC

Prova de conceito que demonstra a exploração.

Patch

Correção, atualização ou mitigação.

CVE não é exploit. CVE identifica a falha. O exploit é uma implementação prática.

4. Fluxo básico de exploração
C:\>raciocínio_ □ ×

Não comece pelo exploit

O exploit vem depois da enumeração.

Antes de procurar código pronto, descubra o que está rodando no alvo.

1. Enumerar

Portas, serviços, versões, diretórios, CMS, plugins e tecnologias.

2. Pesquisar

Buscar CVEs, PoCs, write-ups e documentação.

3. Validar

Conferir versão, pré-requisitos e contexto.

4. Adaptar

Ajustar URL, porta, path, payload, Python 2/3 ou dependências.

5. Executar

Rodar em ambiente autorizado e observar o resultado.

6. Documentar

Anotar comando usado, saída obtida e raciocínio.

nmap -sC -sV -p- <IP>

O resultado do Nmap normalmente indica o próximo passo: serviço, versão, tecnologia web ou caminho de pesquisa.

5. Onde pesquisar exploits
C:\>pesquisa_ □ ×

Fontes úteis

A busca por exploits combina bases conhecidas, buscadores, documentação oficial e leitura de write-ups.

ExploitDB

Banco de PoCs e exploits mantido pela Offensive Security.

Searchsploit

Interface local do ExploitDB no terminal.

GitHub

Repositórios com PoCs, scripts e adaptações.

NVD / CVE

Referências para descrição, impacto e versões afetadas.

Docs oficiais

Úteis para entender parâmetros, endpoints e versões.

Write-ups

Ajudam a entender o caminho usado em labs parecidos.

Priorize fontes que explicam pré-requisitos, versão afetada e impacto. PoC solta sem contexto costuma dar trabalho.

6. Buscas que funcionam
C:\>dorks_ □ ×

Pesquisar melhor economiza tempo

A qualidade da busca muda bastante o resultado.

Combine nome do software, versão, CVE, parâmetro suspeito e tipo de falha.

<software> <versão> exploit
<software> <versão> CVE
<software> <versão> unauthenticated exploit
<software> <versão> SQL injection
<software> <parâmetro> exploit
site:exploit-db.com <software> <versão>
site:github.com <software> <CVE>
site:github.com "m1_idlist" "CMS Made Simple"

Algumas boas buscas parecem estranhas no começo, mas funcionam porque usam termos que aparecem dentro do próprio exploit: nome de parâmetro, endpoint, função vulnerável ou string de erro.

Quando a versão e o nome não bastarem, pesquise por detalhe técnico. Parâmetros e caminhos costumam entregar mais do que o nome genérico do serviço.

7. ExploitDB
C:\>exploitdb_ □ ×

PoCs públicas

O ExploitDB é útil quando você já tem algum dado do alvo: serviço, versão, CMS, plugin ou aplicação.

Exemplos de busca:

site:exploit-db.com vsftpd 2.3.4
site:exploit-db.com wordpress plugin upload exploit
site:exploit-db.com "CMS Made Simple" "SQL Injection"
site:exploit-db.com "CMS Made Simple" "2.2.9"

Ver versão

Confira se a PoC foi feita para a mesma versão ou para uma versão afetada.

Ver requisito

Alguns exploits exigem login, plugin ativo ou configuração específica.

Ver impacto

Pode ser RCE, SQLi, file read, upload, bypass ou DoS.

Ver linguagem

Muitos PoCs antigos estão em Python 2 e precisam de ajuste.

Encontrar o exploit certo é metade do trabalho. A outra metade é entender como ele espera receber URL, caminho, porta e parâmetros.

8. Searchsploit
C:\>terminal_ □ ×

ExploitDB local

O Searchsploit permite pesquisar exploits do ExploitDB direto pelo terminal.

Ele costuma vir instalado no Kali Linux.

searchsploit <software> <versão>

# Exemplos:
searchsploit vsftpd 2.3.4
searchsploit wordpress 5.0
searchsploit cms made simple
searchsploit "CMS Made Simple" 2.2.9

Para abrir um exploit:

searchsploit -x <ID_DO_EXPLOIT>

Para copiar o exploit para a pasta atual:

searchsploit -m <ID_DO_EXPLOIT>

Para atualizar a base:

searchsploit -u

O ID do Searchsploit normalmente é o ID do ExploitDB, não o número do CVE.

9. Baixar e organizar uma PoC local
C:\>local_ □ ×

Trabalhe em uma pasta limpa

Depois de encontrar uma PoC, copie para uma pasta separada.

Assim fica mais fácil testar, editar, criar wordlist, salvar saída e documentar o que foi feito.

mkdir -p ~/ctf/exploits/<alvo>
cd ~/ctf/exploits/<alvo>

searchsploit -m <ID_DO_EXPLOIT>

ls -la
head -n 40 exploit.py

exploit.py

Código original ou adaptado.

notes.txt

Anotações, hipóteses, erros e comandos testados.

wordlist.txt

Lista pequena para testes controlados.

output.txt

Saída salva para consulta.

Evite editar o exploit original sem cópia. Guarde uma versão limpa e outra modificada.

10. Ler antes de executar
C:\>análise_ □ ×

Exploit é código não confiável

Antes de rodar, leia o arquivo.

Mesmo em CTF, exploit público pode estar quebrado, desatualizado ou exigir ajustes.

head -n 60 exploit.py
grep -n "usage\|target\|payload\|RHOST\|LHOST\|url\|port\|password\|wordlist" exploit.py
grep -n "python2\|print \|raw_input\|urllib2\|md5\|requests" exploit.py

Parâmetros

O script espera IP, URL, path, porta, usuário, senha ou arquivo?

Dependências

Ele importa bibliotecas que não existem no ambiente?

Versão

Python 2 ou Python 3? Sintaxe antiga costuma quebrar.

Payload

O que será enviado para o alvo?

Conexão

O exploit abre reverse shell? Precisa de LHOST?

Impacto

Ele lê dado, executa comando, faz upload ou derruba serviço?

Uma PoC antiga geralmente precisa de pequenas correções: print, encoding, imports, URL, timeout, proxy ou tratamento de erro.

11. Ajustes comuns em exploits antigos
C:\>debug_ □ ×

Quando a PoC quebra

Muitos exploits públicos foram escritos para ambientes antigos.

O objetivo é corrigir o suficiente para rodar no lab, sem mudar a lógica da vulnerabilidade.

Python 2 → 3

Trocar print, raw_input, encoding e bibliotecas antigas.

URL

Ajustar barra final, path da aplicação e endpoint.

Dependências

Instalar módulos com pip ou criar requirements.txt.

Wordlist

Usar lista pequena primeiro para validar lógica.

12. Entendendo SQLi time-based blind
C:\>web_ □ ×

Quando o banco responde com tempo

Em uma SQL Injection blind, o resultado da consulta não aparece diretamente na página.

Na variação time-based, o exploit mede o tempo de resposta para descobrir se uma condição era verdadeira.

A lógica é fazer perguntas de sim ou não para o banco.

Pergunta:
"O hash começa com 0?"

Se sim:
sleep(1) → resposta demora

Se não:
sem sleep → resposta normal

Repetindo isso caractere por caractere, o exploit reconstrói valores que não aparecem na resposta HTTP.

LIKE 'a%'

Testa se o valor começa com determinado prefixo.

sleep(1)

Cria atraso quando a condição é verdadeira.

tempo

O script mede a resposta para decidir se acertou.

loop

Cada caractere é descoberto por tentativa.

Essa técnica é lenta por natureza. Cada caractere exige várias requisições.

13. Pista de leitura
C:\>anotação_ □ ×

Strings pequenas contam história

Às vezes, a melhor pista não é o nome do serviço.

Um parâmetro, endpoint ou trecho de payload pode levar direto ao exploit certo.

# Buscas úteis:
"Serviço + Versão" 
"Tipo de Serviço + PoC + Versão"

Quando o nome e a versão não forem suficientes, procure por detalhes que aparecem na aplicação, na URL, no erro ou no código.

Em um CTF real, quem anota parâmetros e caminhos durante a enumeração costuma encontrar o exploit mais rápido.

14. Metasploit
C:\>framework_ □ ×

Automatização com contexto

O Metasploit reúne módulos de exploração, payloads e auxiliares.

Ele acelera testes em laboratório, mas não substitui a análise da vulnerabilidade.

Exploit

Módulo que aproveita uma vulnerabilidade.

Payload

Código executado depois da exploração, como uma shell reversa.

Auxiliary

Módulos de enumeração, scanner e validação.

Options

Configurações exigidas pelo módulo.

msfconsole

search <serviço-ou-CVE>

use <módulo>

show options

set RHOSTS <IP_ALVO>

run

Se um módulo falhar, valide opções antes de descartar a vulnerabilidade: porta, path, SSL, payload, arquitetura e versão.

15. Exemplo de fluxo com Metasploit
C:\>prática_ □ ×

Módulo, opções e execução

O fluxo básico é pesquisar, selecionar módulo, configurar opções e executar.

msfconsole

search vsftpd

use exploit/unix/ftp/vsftpd_234_backdoor

show options

set RHOSTS <IP_ALVO>

set PAYLOAD cmd/unix/interact

run

RHOSTS

Endereço do alvo.

RPORT

Porta do serviço.

TARGETURI

Caminho da aplicação web.

LHOST

Endereço da máquina atacante em payload reverso.

Nem todo módulo usa as mesmas opções. Alguns exigem usuário e senha, outros precisam de path da aplicação, SSL habilitado ou payload compatível.

16. Cheat sheet de exploração
C:\>cheat sheet_ □ ×

Comandos para ter à mão

Use como referência rápida durante a prática.

# 1. Enumeração inicial
nmap -sC -sV -p- <IP>

# 2. Web fuzzing básico
ffuf -u http://<IP>/FUZZ -w /usr/share/wordlists/dirb/common.txt
gobuster dir -u http://<IP>/ -w /usr/share/wordlists/dirb/common.txt

# 3. Buscar exploit localmente
searchsploit <software> <versão>
searchsploit -x <ID>
searchsploit -m <ID>

# 4. Buscar por detalhes técnicos
searchsploit "CMS Made Simple e versão"

# 5. Ler exploit antes de rodar
head -n 60 exploit.py
grep -n "usage\|url\|payload\|wordlist\|password\|hash" exploit.py

17. Checklist antes de executar
C:\>checklist_ □ ×

Perguntas rápidas

  • qual serviço ou aplicação foi identificado?
  • a versão encontrada bate com a PoC?
  • o exploit exige autenticação?
  • o exploit exige plugin, módulo ou configuração específica?
  • o alvo usa HTTP ou HTTPS?
  • o path da aplicação está correto?
  • o código é Python 2 ou Python 3?
  • as dependências foram instaladas?
  • o payload faz o que eu espero?
  • a execução está dentro do escopo do lab?
18. Erros comuns

Alguns erros aparecem muito no começo:

Pular enumeração

Tentar exploit aleatório sem entender o alvo.

Ignorar versão

Usar PoC de outra versão sem validar se ela se aplica.

Não ler código

Rodar exploit sem entender parâmetros, payload e impacto.

Confundir CVE e PoC

CVE identifica a falha. PoC demonstra a exploração.

Errar caminho

Usar URL base errada, path incompleto ou porta incorreta.

Forçar ferramenta

Usar Metasploit sem conferir opções e contexto.

19. Conclusão
C:\>fechamento_ □ ×

Exploit é consequência da análise

A exploração começa antes de executar o exploit.

Ela começa na enumeração, na pesquisa e na validação da hipótese.

Reconhecer

Descobrir serviços, versões e tecnologias.

Pesquisar

Procurar CVEs, PoCs e write-ups.

Validar

Confirmar versão, contexto e pré-requisitos.

Adaptar

Corrigir código, path, dependências e parâmetros.

Executar

Testar apenas no ambiente autorizado.

Registrar

Guardar comandos, saída e raciocínio.