⚠️ USO AUTORIZADO APENAS Esta habilidade destina-se apenas a 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 exato, IP, conta ou recurso 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 somente leitura e forneça apenas orientação defensiva. Prefira um sandbox, VM descartável ou laboratório controlado.

TRIAGEM E VALIDAÇÃO

Uma resposta errada = PARE esta descoberta. Elimine a descoberta. Siga em frente para a próxima classe de teste.

Escopo de "PARAR" nesta habilidade: Os portões desta habilidade eliminam DESCOBERTAS INDIVIDUAIS que falham na validação. Eles NÃO autorizam a parada do engajamento. Eliminar uma descoberta através do Portão das 7 Perguntas significa apenas que essa descoberta não é enviada — todas as outras classes de teste no engajamento ainda estão pendentes. Veja redteam-mindset "Diretiva primária NÃO PARE" para a regra do eixo de cobertura.

"N/A prejudica sua taxa de validade. Informativo é neutro. Envie apenas o que passar em todas as 7 perguntas."

O PORTÃO DAS 7 PERGUNTAS

Pergunte EM ORDEM. Uma resposta errada = PARE imediatamente.

P1: Um atacante pode usar isso AGORA MESMO, passo a passo?

Complete este modelo:

1. Setup:   I need [own account / another user's ID / no account]
2. Request: [exact HTTP method, URL, headers, body — copy-paste ready]
3. Result:  I can [read / modify / delete] [exact data shown in response]
4. Impact:  The real-world consequence is [account takeover / PII read / money stolen]
5. Cost:    Time: [X minutes], Capital: [$0 / $X subscription required]

Se você NÃO PODE escrever o passo 2 como uma requisição HTTP real → ELIMINE-A.

P2: O impacto está na lista de impactos aceitos do programa?

Vá para a página do programa. Encontre "Tipos de Vulnerabilidade" ou "Fora de Escopo".

Níveis comuns:

• Crítico: ATO de qualquer usuário sem interação, RCE, SQLi com exfiltração de dados, bypass de autenticação de administrador
• Alto: Exfiltração em massa de PII, escalonamento de privilégios, SSRF interno com dados, XSS armazenado para todos os usuários
• Médio: IDOR em dados específicos não críticos do usuário, XSS em página sensível que requer clique
• Baixo: Divulgação de informações não sensíveis, clickjacking com PoC

Se o seu bug corresponder a uma exclusão listada → ELIMINE-O.

P3: A causa raiz está em um ativo em escopo?

Confirme:

• O domínio vulnerável está na lista de escopo (não *.internal.target.com)
• É um ativo de produção (não staging/dev, a menos que explicitamente em escopo)
• Não é um serviço de terceiros que a empresa apenas usa (não Stripe, Salesforce, Google Auth)

Se fora de escopo → ELIMINE-O.

P4: Requer acesso privilegiado que um atacante não pode obter realisticamente?

• "O administrador pode fazer X" = risco de centralização = ELIMINE-O (em 99% dos programas)
• "Não administrador pode fazer X que apenas o administrador deveria fazer" = válido
• "Requer acesso físico / dispositivo MFA" = geralmente inválido
• "Requer conta de vítima comprometida para funcionar" = questionável, gravidade baixa na melhor das hipóteses

P5: Isso já é um comportamento conhecido ou aceito?

Pesquise:

1. Relatórios divulgados do programa no HackerOne/Bugcrowd: Ctrl+F nome do endpoint + classe de bug
2. Issues do GitHub no repositório alvo: is:issue label:security ENDPOINT_NAME
3. Changelog/CHANGELOG.md — ele menciona esse comportamento?
4. Documentação da API / documentos de design — está documentado como intencional?

Se for uma decisão reconhecida/de design → ELIMINE-O.

P6: Você pode provar um impacto além de "tecnicamente possível"?

• XSS → mostre roubo real de cookie ou sequestro de sessão, não apenas alert(1) ou alert(document.domain)
• SSRF → atinja um endpoint interno que retorne dados, não apenas um ping DNS
• SQLi → mostre exfiltração real de dados de uma tabela real, não apenas uma mensagem de erro
• IDOR → mostre dados reais de outro usuário na resposta, não apenas um código de status 200

Se você só pode mostrar "tecnicamente possível" → REBAIXE a gravidade, não elimine.

P7: Esta é uma classe de bug conhecida como inválida?

Verifique a lista NUNCA ENVIAR abaixo. Se estiver nesta lista sem uma cadeia → ELIMINE-O.

A ARMADILHA DA ORDEM DAS CAMADAS — leia antes de reivindicar qualquer bypass de autenticação

Um erro de validação NÃO prova que você passou pela autenticação.

…