Methodology

Bug Bounty Methodology

Primeiro passo sempre, antes mesmo de começar scans e os caralho, é entender o alvo
como empresa.
Tem que entender alguns pontos do alvo para poder focar melhor a caça. Como por
exemplo:

Entender o negócio: Qual o negócio da empresa? O que ela faz? O que ela vende?
Como ela ganha dinheiro? Qual o fluxo mais crítico da aplicação? Quais são as
operações importantes?
Mapear o fluxo: Desenhar o fluxo de uma operação importantes (ex: compra,
transferência, postagem, e afins...)
Abusar do fluxo: O que aconteceria se eu pular uma etapa? E se eu enviar valores
negativos? E o que aconteceria se eu, por ventura, mudasse o id que aparece? E se eu
tentar usar dois navegadores ao mesmo tempo com a mesma conta fazendo a mesma
coisa? (Race Condition)
Exemplo prático: Em um e-commerce, adicionar um item caro ao carrinho, aplicar um
cupom de desconte, depois alterar a quantidade do item para um valor negativo. A
lógica de programação pode subtrair o valor negativo, efetivamente adicionando mais
desconto e permitindo a compra do item por um preço irrisório ou até mesmo zerado.

Dá pra abusar também do Canvas do Obsidian para poder desenhar os fluxos da aplicação,
dessa forma fica mais "fácil de entender" como a aplicação funciona e como poderia ser
contornada.

Mentalidade Ideal

Trabalhe apenas com metas dentro do escopo. Não perca tempo com coisas que não
vão te recompensar.
Respeite as regras de divulgação e as políticas do programa.
Trate cada teste como um trabalho profissional. Ou seja, mantenha-se organizado.
Faça anotações curtas. Salve comandos e descobertas.
Espere o fracasso. Muito fracasso, muito mesmo. Aprenda com o que ocorreu e siga em
frente.

A consistência vence o talento se o talento for preguiçoso.

Priorizar Valor Vs Esforço

Nem todo o endpoint vale a pena testar profundamente. Pontue cada ativo pelo impacto
potencial e pelo tempo necessário com base na consideração daquilo para a empresa.
Exemplo de pontuação rápida:

Impacto: 1-5 (5 sendo maior gravidade e um baixa gravidade)

Esforço: 1-5 (5 sendo um teste demorado e 1 um teste rápido)
Assim, concentrar primeiro no alto impacto com baixo esforço.
As vitórias vêm da repetição dessa seleção.

Recon Incial

Antes de testar qualquer coisa, é crucial conhecer o alvo, por dentro e por fora. É aí que
começamos pelo Recon, que é a base para o Bug Hunt.
O Recon é crucial para obter as informações necessárias sobre a aplicação. A primeira
etapa dela sendo full automatizada se quiser, pode nos fazer obter algumas informações
úteis como "Low-hanging fruits" na superfície de ataque, tipo Open Redirect, Subdomain
Takeover e afins. Importante dar atenção a isso!

Tools Pra Recon

Recon Passivo: Sem interação direta com o alvo. Dá um bom contexto do alvo e com
pouco ou nenhum ruído.

Uncover: Ferramenta para obter hosts expostos na internet usando APIs como Shodan,
FOFA e afins.
Subfinder: Encontra subdomínios de fontes públicas
Chaos: Client do dataset Chaos da ProjectDiscovery para enumeração de subdomínios
CTFR: Análise de Certificados e transparência de certificados sem utilizar brute force
Assetfinder: Busca ativos como subdomínios
Findomain: Busca por subdomínios
OneForAll: Ferramenta em Python de integração foda para enumeração de
subdomínios
Netlas: Scanner não intrusivo para descoberta de ativos
[Link]: Pesquisa de certificados para subdomínios
TLSX: TLS grabber para análise de certificados
Waybackurls: Obtém URLs arquivadas antigas
Waymore: Obtém através de crawling e spidering inúmeras URLs arquivadas
Waybackpack: Obtém também URLs históricas.
GoSpider: Um spider rápido feito em go
Hakrawler: Crawler para URLs e arquivos JavaScript
 Katana: Framework em go para crawling e spidering
Gau (GetAllURLs): Agrega URLs de múltiplas fontes
theHarvester: Ferramenta de OSINT para coleta de emails, nomes, subdomínios, IPs e
URLs de fontes públicas
GooFuzz: Ferramenta rápida para realizar buscas através de google dorks
GithHub Dorks: Encontra segredos do código público
Buscar também por Github Actions. Jenkins e CircleCI
Google Dorking: Encontrar no google conteúdo interessante como:
loin_pages, admin_panels, dashboard_pages, stackoverflow, social_media,
project_management, code_sharing, config_files, jenkins, wordpress_files,
php_error, exposed_documents, db_files, git_exposed

Recon Ativo: Faz varredura direta, em contato com o alvo. Fazer uma varredura pequena e
lenta não é tão ruidoso e pode evitar perder ativos.

Amass: Enumeração poderosa de subdomínios tanto ativa quanto passiva e com

técnica de bruteforce de DNS e scraping avançado
Sublist3r: Busca em motores como Google, Yahoo, Bing, Baidu, Ask, Netcraft,
Virustotal, entre outos
KSubdomain: Ferramenta extremamente rápida para enumeração de subdomínios
EXTREMAMENTE ruidosa - Full chinês
Sudomy: Usa técnicas de OSINT e de enumeração passiva e ativa para buscar
subdomínios
PureDNS: Resolução de Domínios e obtenção de subdomínios por forcabruta
DNSX: Resolução de DNS rápida e ativa
Masscan: Resolução massiva de DNSs
HTTPX: Verifica se há hosts ativos
Nmap: Scanner de portas e serviços
Naabu: Scanner de portas rápido e potente
Rustscan: Scanner de portas extremamente rápido, mas pode perder algo no caminho
ou dar block.
Whatweb: Detectar tecnologias - a partir daqui!
Wappalyzer: Analise de tecnologias empregadas pelas aplicações
Wappalyzergo: O Wappalyzer mas em go, mais rápido
Wafw00f: Detectar WAFs
Trufflehog: Validador e scanner de segredos e coisas expostas.

Filtragem:
Depois de tudo isso tem que fazer um processamento do que foi obtido, pra isso, tem que
remover as duplicadas, podendo usar sempre para adicionar aos arquivos o anew e
filtrando com uro as URLs duplicadas com valores diferentes inseridos nos parâmetros,
podendo usar também o unfurl . Além de filtrar através do content_length e
page_title . Crucial também filtrar extensões irrelevantes para que elas não poluam o
recon, como png, jpg, jpeg, gif, mp4, mpeg, mp3 e afins.
Depois disso, aplicar gf patterns para categorização, alguns como:

debug_logic
idor
interestingEXT
interestingparams
interestingsubs
lfi
rce
redirect
sqli
ssrf
xss
Entre outros pertinentes.
Interessante também é, usar para a Resolução de DNSs a ferramenta alterx que criar
inúmeras possibilidades de subdomínios para testar com bruteforce.
Abusar do uso do tr e do awk , bem com sort , anew , uro e unfurl .

Directory & File Fuzzing: Realizar a descoberta de diretórios e arquivos ativamente nas
aplicações

Dirsearch: Força bruta para vasculhar diretórios

Ffuf: Fuzzer rápido escrito em go e bem personalizável
Nessa etapa as wordlists são EXTREMAMENTE IMPORTANTES. Então usar sempre
wordlists confiáveis e úteis, como as de Wordlists realmente úteis, exemplo as wordlists
de Seclists :
Discovery\Web-Content\[Link]
Discovery\Web-Content\[Link]
Discovery\Web-Content\raft-*-[Link]
Discovery\Web-Content\raft-*-[Link]

* O motivo do asterisco é justamente ser um coringa para todos os tamanhos, small,

medium e large das rafts.

Screenshot Gathering: Capturas de telas para agilizar o processo de reconhecimento

EyeWitness: Screenshots de aplicações web automatizados

GoWitness: Mesma coisa que o EyeWitness, mas mais rápido por ser em go

Importante Aqui
 Usar o reconhecimento ativo e passivo sempre. Ambos para maior cobertura.
Organizar os resultados em pastas e arquivos como [Link] , [Link] ,
[Link] , etc.
Não pular o reconhecimento em hipótese alguma, mesmo que demore horas.

Exemplo De Fluxo Completo:

Após O Recon Inicial - Enumeração E Verificação De

Vulnerabildiades

Pensamos da seguinte forma: "Agora tenho uma caralhada de URLs, subdomínios e afins, o
que faço?"

Objetivo:Encontrar Pontos Fracos Na Aplicação

Agora que temos URLs, subdomínios, diretórios e o caralho, é hora de cavar mais fundo. É
agora que testarmos ativamente as coisas.

Tools Para Enumeração

Nuclei: Scan de vulnerabilidades ativo e automatizado com base em templates

Nikto: Scanner de vulnerabilidades ativo e classico com inúmeras techs prontas
Dalfox: Scanner avançado de XSS com automação
Xsstrike: Ferramenta para busca e testes de XSS
CRLFuzz: Scanner de vulnerabilidades de CRLF injection
S3Scanner: Detecta Buckets S3 mal configurados
CloudEnum: Detecta buckets testando nomes baseados no nome da empresa também,
e verifica se tem as permissões de leitura/escrita públicos.
MicroBurst: Enumeração de Blobs e containers da Microsoft Azure
JSScanner: Scanner de arquivos JavaScript
Arjun: Descoberta de parâmetros GET/POST
LinkFinder: Vazamento de informações e dados.
GF Patterns (já visto acima): Filtros para bugs comuns (com xss, ssrf e afins)
ParamSpider: Encontra parâmetros ocultos
 Parth: Automação para descoberta de parâmetros
Kxss: Ferramenta para encontrar injeções de XSS refletida
Secretfinder: Ferramenta para analisar arquivos em busca de segredos vazados
SQLMap: Ferramenta para validação de Injeção de SQL
InQL: Ferramenta focada e GraphQL para analise
Clairvoyance: Outra ferramenta focada em GraphQL para analise de endpoints e
graphos.

Antes De Partir Para Os Testes Manuais, Mapeie a Superfície

Pegue os resultados do reconhecimento, crie um mapa, pode ser uma lista com os ativos e
algumas anotações sobre os ativos, ou um mapa mental.
Por exemplo:

[Link] - Fluxo de autenticação, formulário de upload, endpoints de

API.
[Link] - Endpoints JSON, cabeçalhos de token, políticas de CORS.
[Link] - Ativos estáticos, bibliotecas antigas
Dá para ser uma tabela simples no obsidian. Dessa forma se torna um manual do alvo.

Após a Enumeração - Teste E Exploração Manual

Encontrei algo, faço oque?

Objetivo: Confirmar E Explorar O Bug

Encontrou algo suspeito? Agora vamos testar corretamente. E aqui que separamos o joio do
trigo. Os script kidies dos hackers reais.

Ferramentas Que Serão Necessárias

Burp Suite: O Proxy dos proxys. Extensões excelentes, repeteater, intruder,

decodificação, dificilmente alguma ferramenta supera ele pra isso
OWASP ZAP: Uma alternativa open-source ao Burp, muito boa, com scanner
automatizado
Frida: Injeção de scripts em runtime de aplicação mobile, bypass de SSL pining e
manipulação de funções.
 Postman: Excelente para testar APIs
curl: Teste rápido só para uma pequena verificação
Navegador (com dev tools): Crucial para realizar os testes;

Exemplos De Testes Manuais

Alterar ID na solicitação: /user?id=101 → /user?id=102

Tente inserir cargas úteis como <script>alert(1)</script>
Remova tokens ou cookies e observe a resposta
Tente adulteração do método HTTP: PUT , DELETE , etc.
Solicitação de repetição com cabeçalhos modificados

Cabeçalhos Para Modificar

X-Forwarded-For
X-Forward-For
X-Forwarded-Host
X-Host
Ogirin
Referer
User-Agent
Authorization

Teste Com Intenção

Testar sem intenção é somente ruído. Para cada item de alta prioridade, pergunte: O que
quebraria isso aqui?

Áreas comuns para testar:

Autenticação e gerenciamento de sessões

Problemas de IDOR e controle de acesso
Upload e desserialização de arquivos
Falhas na lógica de negócios
Endpoints de API e Rate Limits
CORS e vazamento de tokens
Sempre trabalhar em etapas pequenas e lógicas. Documentar cada request e response.
De Atenção Especial Aos Teste Em Núvem

Dada a migração massiva de ativos para a nuvem, podemo expandir A05 (Security
Misconfiguration) para incluir a busca por IAM Roles mal configuradas e Azure/GCP
Buckets, que muitas vezes são esquecidos em favor do AWS S3.

Encontrou Algo? Validar E Reproduzir

Se encontrar alguma coisa, não comemorar antes da hora.

Reproduz o teste de forma limpa, mais de uma vez.

Cria um caso de teste mínimo, que qualquer pessoas consiga executar.
Registre as etapas, solicitações, payloads e respostas exatas.
Faça capturas de tela
Salvar solicitação/resposta no Burp
Salve tudo com data e hora
Copie comandos curl para seu relatório

Sobre O Relatório

Encontrou alguma vulnerabilidade? Agora o relatório tem que brilhar e deve ser bom o
suficiente pra que a avó de alguém consiga replicar. Se não conseguirem reproduzir, não
receberá.
Relatórios bons são pagos, relatórios ruins são ignorados, então é importante manter o
relatório claro, curto, objetivo e funcionar.

Tem um modelo genérico em Modelo de relatório genérico. Mas o crucial para ter em um
relatório é:

Título: Curo e específico, tipo [ATO - Account Take Over] XSS Reflected result in Accout
Take Over with one click
Impacto: O que um invasor pode fazer? Por que isso importa para a empresa?
Etapas para reproduzir: Etapas numeradas, e quanto menos melhor.
PoC: Solicitações, payloads, capturas de tela, vídeos se necessário.
Correção: Sugestão curta de correção ou ideia de mitifação.
Gravidade: A gravidade sugerida, normalmente baseada no CVSS.
Anexe como evidência os logs e arquivos do Burp se permitido.
Usar marcadores e linhas curtas. O revisor não tem necessidade de adivinhar.
Algumas Dicas Para O Relatório São:

Use sempre inglês (e sem termos técnicos pesados)

Use marcadores para facilitar a leitura
Mencione impacto nos negócios
Dê sugestões para correção da vulnerabilidade
Inclua capturas de tela, request com curl e o retorno, arquivos do burp, vídeo (se for
necessário), o que precisar para provar a vulnerabilidade.
Se pedirem mais informações, não se acanhe, de mais informações.
Se for triado como fora do escopo ou não aplicável, pergunte educadamente o motivo.
Se a empresa estiver lenta para triar, faça o acompanhamento após um tempo razoável.

Rotina Diária

Tentar sempre manter uma rotina. Blocos curtos diários e repetição irão criar resultados
melhor do que dias esparsados.

Ideal umas 4-5 horas, mas umas 3 bem focadas ajudam. Caça ativa.
Um alvo só, ou um domínio.
1-2 horas - estudo e writeups das evidências
Um report clean com vídeos rápidos se necessário e prints.
1 horas - Aprendizado e estudo de técnicas e ferramentas
Um mergulho focado em ferramentas e técnicas
30 minutos - Perfis e divulgação
Atualizar Hackerone, BugCrowd, Intigriti, LinkedIn, Github, Portfólio, Currículos e
plataformas de currículos.
30 minutos - Anotações e reflexões sobre o feito e estudado
Salvar comandos, resultados e próximos possíveis alvos.

Considerar isso como uma visão do dia a dia.

Metas

Semanalmente subir um artigo sólido no Medium, LinkedIn e upar no portifólio.

Semanalmente enviar pelo menos 5 relatórios de alta qualidade (não necessáriamente
serem aprovados, mas relatados)
Mensalmente atingir algum marco de receita ou aprendizado interessante
Revisar tentativas fracassadas.
Extrair padrões
 Criar uma lista de verificação para evitar os mesmos erros.

Erros Comuns a Evitar

Pulverizar testes e rezar para o escaner retornar algo monetizável.

Rezar para o scan sem alvo focado dar certo
Anotações ruins (acaba esquecendo como chegou até ali)
Relatórios ruins com registros barulhentos
Ignorar o escopo e política

Pequenas Vitórias

Um artigo claro por semana.

Uma pequena automação que economiza seu tempo.
Uma atualização de perfil que transforma visualizações em shows.
Essas coisas fazem sentido.

Dica de Ouro: O segredo não é a ferramenta, é a metodologia. Sempre rode

um checklist de sanidade: eu entendi o que a aplicação faz e onde ela
armazena os arquivos?
§

Testes Por Categoria Da OWASP Top 10

Categoria de Casos de Teste/Ações Payloads/Técnicas Comuns

Vulnerabilidade Específicas
A01: Quebra de Manipular IDs em id=123 para id=124 ,
Controle de URLs/requisições para /admin/dashboard , ../ para Path
Acesso (Broken acessar recursos de outros Traversal, {"role": "user"} para
Access Control) usuários (IDOR (Insecure {"role": "admin"} , forçar navegaç
Direct Object Reference)), para /admin , /config , /reports
alterar parâmetros de Original-URL , X-Rewrite-URL , X
requisição (HTTP, JSON, Forwarded-For .
XML) para elevar privilégios.
Tentar acessar URLs de
admin sem estar logado ou
Categoria de Casos de Teste/Ações Payloads/Técnicas Comuns
Vulnerabilidade Específicas
com um usuário comum.
Testar acesso a recursos
restritos (pastas, arquivos,
endpoints) sem autenticação
ou com autenticação de
menor privilégio. Testar
bypass em restrições de
acesso baseadas em IP,
tempo ou outras regras de
negócio.
A02: Falhas Procurar por dados sensíveis Análise de tráfego de rede (Wireshark
Criptográficas (senhas, tokens, informações Burp Suite). Verificar headers de
(Cryptographic pessoais) trafegando em segurança (HSTS). Busca por md5 ,
Failures) HTTP sem criptografia ou sha1 , DES , RC4 no código. Testar
com HTTPS mal configurado tokens JWT com alg:none , força br
(protocolos fracos, em chaves/senhas fracas.
certificados
expirados/inválidos). Verificar
o uso de algoritmos de hash
fracos (ex: MD5, SHA1 para
senhas) ou algoritmos de
criptografia obsoletos. Testar
a exposição de chaves
criptográficas em código-
fonte, configurações ou
repositórios públicos. Análise
de tokens de sessão ou
JWTs para falhas de
integridade (ex: alg:none ).
A03: Injeção Testar todos os campos de ' OR 1=1;-- - (SQLi),
(Injection) entrada (URLs, parâmetros <script>alert([Link])
POST/GET, cabeçalhos </script> (XSS), ; cat /etc/pas
HTTP, cookies, formulários, ou & systemctl reboot (Command
JSON, XML) para injeção de Injection), *(cn=admin) (LDAPi). Us
caracteres especiais. ferramentas de fuzzing como Ffuf o
Verificar vulnerabilidades sqlmap , XSS Hunter para XSS fora
como SQL Injection (SQLi), banda. } (Template Injection).
Cross-Site Scripting (XSS),
Command Injection, LDAP
Injection, Template Injection.
Observar mensagens de erro
detalhadas ou
comportamento inesperado
do aplicativo.
A04: Design Procurar por funcionalidades Análise de fluxogramas e diagramas d
Inseguro que, por design, são arquitetura, revisão de especificações
Categoria de Casos de Teste/Ações Payloads/Técnicas Comuns
Vulnerabilidade Específicas
(Insecure inerentemente inseguras (ex: funcionais e requisitos de segurança.
Design) lógica de negócio falha, Testes de lógica de negócio: Race
permissões excessivas por Conditions (usando Burp Sequencer o
padrão, fluxos de trabalho scripts), Bypass de etapas, Client-Sid
que podem ser bypassados). Enforcement (modificar JS para bypas
Analisar a arquitetura da validação). Uso de recon para identific
aplicação em busca de bibliotecas e frameworks.
pontos cegos, confiança
excessiva em componentes
de cliente ou falta de
validação robusta. Identificar
uso de bibliotecas de
terceiros com
funcionalidades
desnecessárias ou
perigosas. Testar limites de
uso e condições de corrida
em funcionalidades críticas.
A05: Procurar por arquivos de /.git/config , /.env , /server-
Configuração configuração expostos (ex: status , /manager/html , robots.
Incorreta de .git , .env , [Link] . nmap -sV <IP> .
Segurança [Link] ), credenciais Ferramentas como [Link] para
(Security padrão ( admin:admin ), SSL/TLS. Headers HTTP ausentes ou
Misconfiguration) listagem de diretórios incorretos. Configurações de seguran
habilitada, mensagens de padrão ou fracas.
erro detalhadas. Verificar
cabeçalhos de segurança
ausentes ou mal
configurados (CSP, HSTS, X-
Frame-Options, X-Content-
Type-Options). Testar o uso
de portas e serviços
desnecessários. Analisar
permissões de arquivos e
diretórios ( 777 ).
A06: Identificar todas as Ferramentas de análise de dependên
Componentes bibliotecas, frameworks, APIs ( npm audit , pip-audit , Composer
Vulneráveis e de terceiros e outros audit , [Link] , Dependency-
Desatualizados componentes utilizados pela Track ). Análise de arquivos de lock
(Vulnerable and aplicação. Verificar se há ( [Link] , [Link] ,
Outdated versões desatualizadas ou [Link] ). Banners de ver
Components) com vulnerabilidades em headers HTTP. Busca por CVEs
conhecidas (CVEs). Testar o conhecidas para versões específicas
uso de funcionalidades softwares.
inseguras ou não
intencionais de componentes
de terceiros. Buscar por
Categoria de Casos de Teste/Ações Payloads/Técnicas Comuns
Vulnerabilidade Específicas
dependências não utilizadas
ou não mantidas.
A07: Falhas de Testar ataques de força bruta admin , password (credenciais padr
Identificação e ou enumeração de usuários Ferramentas como Hydra , Medusa
Autenticação em telas de login, força bruta. Teste de tempo de respos
(Identification recuperação de senha e para enumeração de usuário. Modifica
and registro. Verificar cookies de sessão, JWTs (ver A02).
Authentication mecanismos de bloqueio de Bypass de 2FA. Host header poison
Failures) conta e proteção contra rate
limiting. Analisar a força das
senhas permitidas e o
armazenamento seguro de
credenciais. Testar
vulnerabilidades em tokens
de sessão (ex:
previsibilidade, reuso,
expiração inadequada).
Procurar por phishing ou
Multi-Factor Authentication
(MFA) fraco ou bypassável.
A08: Falhas de Testar para Deserialização Usar ferramentas como ysoserial para
Software e Insegura se a tecnologia for gerar payloads de deserialização.
Integridade de conhecida por isso (Java, Modificar payloads de entrada para ve
Dados (Software .NET, PHP, Python). Verificar como a aplicação lida com dados
and Data a integridade de atualizações corrompidos ou maliciosos. Procurar
Integrity de software, dependências e endpoints de upload de arquivos que
Failures) dados críticos, validam tipo/integridade. Análise de
especialmente aqueles que configurações de CI/CD, hooks de git
vêm de fontes não
confiáveis. Procurar por
falhas na cadeia de CI/CD
que permitam injeção de
código ou modificação de
artefatos. Analisar se hashes
ou assinaturas digitais estão
sendo usados para validar a
integridade.
A09: Falhas de Verificar se eventos críticos Tentar múltiplas tentativas de login co
Registro e de segurança (tentativas de credenciais inválidas e verificar os log
Monitoramento login falhas, acessos não Realizar acessos não autorizados
de Segurança autorizados, modificações de intencionais e verificar se são logados
(Security dados sensíveis) estão Desativar funções de segurança (se
Logging and sendo registrados. Analisar a possível) e verificar logs. Procurar po
Monitoring suficiência e clareza dos logs detalhados de erros que possam
Failures) logs, garantindo que vazar informações sensíveis.
contenham informações úteis
Categoria de Casos de Teste/Ações Payloads/Técnicas Comuns
Vulnerabilidade Específicas
para investigação (IP de
origem, usuário, timestamp,
ação realizada). Testar se há
alertas ou mecanismos de
resposta a incidentes para
atividades suspeitas.
A10: Identificar funcionalidades [Link] ,
Falsificação de que fazem o servidor buscar [Link] ,
Solicitação do um recurso externo (ex: [Link]
Lado do gerador de PDF a partir de data/ . Fuzzing de IPs e portas, uso
Servidor (Server- URL, webhooks, importação diferentes esquemas de URL ( ftp://
Side Request de imagens de URL, gopher:// ). Encaminhadores de UR
Forgery - SSRF) validação de RSS feeds). redirects.
Tentar fornecer IPs internos
( [Link] ,
[Link] ,
[Link] )
ou URLs de serviço de
callback como Beeceptor
para verificar a
acessibilidade a recursos
internos ou a serviços
externos não intencionais.

Fontes E Referências

Laboratórios Práticos:
PortSwigger Web Security Academy (Essencial)
Hack The Box
TryHackMe
Guias e Checklists:
OWASP Web Security Testing Guide (WSTG)
OWASP Mobile Application Security Testing Guide (MASTG)
Livros:
"The Web Application Hacker's Handbook"
"Real-World Bug Hunting: A Field Guide to Web Hacking"
Fontes:
[Link]
[Link]
2025-with-tools-commands-and-tips/
[Link]
workflow/