⚠️ USO AUTORIZADO APENAS Esta habilidade é apenas para fins educacionais ou avaliações de segurança autorizadas. Você deve ter permissão explícita e por escrito do proprietário do sistema antes de usar esta ferramenta. O uso indevido desta ferramenta é ilegal e estritamente proibido.

Portão de confirmação obrigatório Antes de executar qualquer comando que sonde, explore, altere, persista, extraia dados ou tente acesso a credenciais contra um alvo:

1. Peça ao usuário para declarar o URL, IP, conta ou recurso exato do alvo.
2. Peça ao usuário para confirmar a autorização por escrito e o escopo permitido.
3. Mostre o(s) comando(s) exato(s) e explique seu efeito esperado.
4. Aguarde a confirmação explícita na conversa atual.

Sem essa confirmação, permaneça apenas em modo de leitura e forneça apenas orientação defensiva. Prefira um sandbox, VM descartável ou laboratório controlado.

Metodologia de Bug Bounty: Fluxo de Trabalho + Mentalidade

Orquestrador mestre para sessões de caça. Combina o fluxo de trabalho não linear de 5 fases com a estrutura de pensamento crítico que separa os 1% melhores caçadores do resto.

PARTE 0: CONFIRMAÇÃO DE MODO (Antes de Tudo)

Confirme o tipo de engajamento antes de decidir o que conta como uma descoberta. O mesmo alvo produz um formato de relatório diferente dependendo de qual modo se aplica. Errar nisso é o maior desperdício de tempo neste fluxo de trabalho — responda explicitamente antes da Fase 0.

Regra rígida: Antes que a Fase 0 seja executada, escreva o tipo de engajamento como a primeira linha em suas notas de caça. Se você não puder respondê-lo a partir da instrução do usuário, PERGUNTE uma vez. Não presuma — o erro custa a você e ao triador.

Lição de um engajamento autorizado: A primeira passagem neste alvo produziu 5 achados de higiene (SP2013 EoL, CSP permissivo, rastros de pilha) enviados no formato de red team. O engajamento era bug bounty. Os achados teriam sido N/A como "informacional, sem impacto demonstrado". Após a passagem corrigida com higiene como contexto, não como achado, o mesmo alvo rendeu 11 bugs com impacto demonstrado, incluindo 3 Críticos.

PARTE 1: MENTALIDADE (Como Pensar)

Princípio Central

Caçar não é "encontrar um bug" — é "provar um cenário de ataque". Pense como um atacante com um objetivo específico, não como um scanner procurando padrões.

Disciplina Diária: Definir, Selecionar, Executar

Antes de tocar em qualquer ferramenta:

1. Definir: "Hoje eu ataco [funcionalidade/domínio] para alcançar [impacto CIA]"
2. Selecionar: Escolha 1-2 classes de vulnerabilidade (IDOR, Condição de Corrida, etc.)
3. Executar: Foque APENAS nas técnicas selecionadas. Sem desvios.

5 Objetivos Finais (Escolha Um Por Sessão)

1. Confidencialidade — roubar dados que o atacante não deveria ver
2. Integridade — modificar dados que o atacante não deveria alterar
3. Disponibilidade — interromper o serviço (apenas DoS no nível do aplicativo)
4. Tomada de Conta — controlar a conta de outro usuário
5. RCE — executar comandos no servidor

4 Domínios de Pensamento

1. Pensamento Crítico (análise profunda)

Questione os limites de confiança:

• Controle de frontend desabilitado? Envie a solicitação diretamente via proxy
• Cookie user_role=user? Mude para admin
• price=1000 em POST? Mude para 1
• <script> bloqueado? Tente <img onerror=...>

Engenharia reversa da psicologia do desenvolvedor:

• Recurso A tem verificações de autenticação -> Recurso B semelhante (adicionado recentemente) provavelmente não tem
• Fluxos complexos (cupom + pontos + reembolso) -> Casos extremos têm bugs
• /api/v2/user existe -> /api/v1/user ainda funciona com autenticação mais fraca?

Experimentos "E se":

• Pular checkout -> acessar /checkout/success diretamente
• Pular 2FA -> navegar para /dashboard
• Enviar solicitação de cupom 10x simultaneamente -> Condição de corrida?

…