⚠️ 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 em, extraia dados de 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 somente leitura e forneça apenas orientação defensiva. Prefira um sandbox, VM descartável ou laboratório controlado.

HUNT-BRUTE-FORCE — Limitação de Taxa / Força Bruta / Enumeração

Nota de base: esta habilidade é construída a partir de classes de técnicas publicadas, não de um conjunto curado de relatórios nomeados do HackerOne. report_count é intencionalmente 0 — não cite um pagamento exato ou ID de relatório que você não possa verificar. Onde um caso público é bem documentado (por exemplo, pesquisa de corrida/rotação de OTP de redefinição de senha do Instagram de Laxman Muthiyah, 2019–2021), ele é nomeado abaixo como uma referência de técnica, não uma reivindicação de pagamento.

Alvos de Joias da Coroa

Força bruta de OTP (6 dígitos = 1.000.000 combinações) sem limite de taxa efetivo = Bypass crítico de ATO.

Cadeias de maior valor:

• Força bruta de OTP / 2FA → Bypass de MFA → ATO — sem limite de taxa efetivo em /verify-otp, todo o espaço de chaves 000000–999999 alcançável
• Força bruta de token de redefinição de senha — tokens curtos/previsíveis/não expirantes + sem limite de taxa → ATO (o caso do Instagram de 2019 combinou um código de redefinição de 6 dígitos, sem limite de taxa por origem da solicitação e rotação de IP para tornar 10^6 tratável)
• Enumeração de nome de usuário/e-mail → stuffing de credenciais direcionado — válido/inválido distinguível por string de resposta, código de status ou tempo, em seguida, pulverizado com corpora de violação
• Força bruta de código de cupom / cartão-presente / referência — sem limite de taxa na validação de código → impacto financeiro
• ReDoS — entrada controlada pelo atacante atinge uma regex de backtracking catastrófica → exaustão de CPU → DoS

Prioridade de Teste Autônomo

Trabalhe dentro do seu limite de turnos — priorize sinal sobre volume.

Você não pode fazer força bruta em milhões de combinações em testes automatizados. Concentre-se em duas coisas: (1) pulverização de credenciais com os candidatos mais prováveis e (2) detecção se o limite de taxa existe ou não.

Estratégia:

1. Identifique o endpoint de login e os nomes de parâmetros esperados (nome de usuário/e-mail, senha).
2. Tente credenciais fracas/padrão prováveis para o contexto do alvo — credenciais de administrador padrão para a pilha do aplicativo, senhas simples para ambientes de teste, credenciais visíveis em outro lugar no aplicativo (por exemplo, nomes de usuário expostos em perfis, senhas padrão na documentação).
3. Após 3-5 tentativas falhas, verifique os sinais de limite de taxa (status 429, mensagem "muitas tentativas", aparecimento de CAPTCHA, mensagem de bloqueio de conta). A ausência deles = limite de taxa ausente = vulnerabilidade.
4. Use codificação de formulário para formulários de login tradicionais, JSON para endpoints de login de API REST.

O que procurar como sucesso:

• Token de sessão ou JWT no corpo da resposta ou cabeçalho Set-Cookie
• Redirecionamento para o painel autenticado
• Corpo da resposta que difere da linha de base de login falho

Enumeração de nome de usuário (descoberta separada): Tente um nome de usuário conhecido como válido vs um aleatório. Se a mensagem de erro for diferente ("Senha incorreta" vs "Usuário não encontrado") ou o tempo de resposta for diferente → vulnerabilidade de enumeração de usuário, mesmo sem um login bem-sucedido.

CRÍTICO: Quatro estados de limite de taxa — não os colapse

Um 200/401 sem 429 não significa "sem limite de taxa". Uma habilidade de limite de taxa que verifica apenas 429/bloqueio produz falsos negativos. Classifique a defesa ANTES de concluir, enviando um surto de ~50 solicitações e observando a resposta completa (status, corpo, cabeçalhos, latência e sucesso downstream):

…