De CTF a Bug Bounty: Como Ganhei 7 Milhões de Reais em um Mês e Meio com a Ajuda da IA

Olá a todos! Enquanto alguns especialistas debatem nos comentários se as redes neurais podem encontrar vulnerabilidades de forma eficaz, decidi testar isso na prática. Meu nome é Nuit, tenho 18 anos, estou estudando e este ano farei o ENEM, planejando seguir carreira em Segurança da Informação (SI). Paralelamente, me dedico ao bug bounty. Nos últimos mês e meio, consegui ganhar mais de 7 milhões de reais na busca por vulnerabilidades. Abaixo, contarei sobre meu caminho: como me esgotei em CTFs e comecei no bug bounty, como uso redes neurais para encontrar falhas – e também analisarei um caso que me rendeu um milhão e meio de reais.

Este artigo tem caráter puramente informativo e educacional, não constituindo instrução ou incitação à prática de atos ilícitos. Os materiais descritos destinam-se a aumentar a conscientização sobre possíveis vulnerabilidades e métodos de prevenção. Qualquer teste de segurança só é permitido com a permissão explícita do detentor dos direitos dos respectivos recursos ou no âmbito de um programa oficial de bug bounty. Ações não autorizadas podem violar a legislação. O autor do artigo não incentiva nem apoia o uso indevido das informações apresentadas e não se responsabiliza pelo seu uso para fins ilícitos. Lembre-se de que é importante prestar atenção à proteção de seus dados e usar as informações do artigo exclusivamente para fins legais.

Por que tive que sair do CTF e como cheguei ao bug bounty

Tudo começou com as clássicas competições CTF. Joguei por muito tempo e gostei, especialmente da categoria web. Mas com o tempo, veio o esgotamento: é difícil passar duas noites inteiras resolvendo tarefas complexas e específicas, quando o máximo que você consegue é uma camiseta de brinde por ganhar em primeiro lugar. Quando me cansei completamente, conhecidos me disseram que era possível fazer praticamente a mesma coisa, mas ganhar dinheiro decente com isso – foi assim que cheguei ao bug bounty.

Os primeiros resultados não apareceram imediatamente. Levei bastante tempo para encontrar meu primeiro bug pago. Foi um bypass de licenciamento em uma grande empresa, pelo qual recebi 6.000 rublos. Uma quantia pequena, mas o próprio fato de que se pode ganhar dinheiro real por uma vulnerabilidade encontrada me motivou.

Quase imediatamente depois disso, consegui encontrar duas vulnerabilidades de criticidade alta. Aliás, para encontrar uma delas do zero, levei literalmente dez minutos. Depois disso, o processo começou a ganhar ritmo: em um mês e meio desde o primeiro pagamento, o ganho total ultrapassou 7 milhões de rublos.

O que mais gosto no bug bounty são duas coisas:

• Desafio técnico. Adoro a ideia de que, na minha idade, encontro vulnerabilidades perigosas em corporações sérias.
• Recompensas. Claro, a parte financeira do bug hunting é gratificante, e eu gasto não mais que 5 horas por dia, geralmente bem menos.

Como as redes neurais estão mudando o jogo no bug hunting

Sendo direto, sem IA, eu não teria ganhado tanto. Peguei meus desenvolvimentos do CTF e os adaptei para o bug bounty. Não é segredo para ninguém que a IA pode encontrar vulnerabilidades de forma muito mais eficaz do que pesquisadores. Além disso, é mais interessante simplesmente receber um resumo dos vetores vulneráveis e aprimorá-los, pulando a fase de reconnaissance.

Um conselho importante ao trabalhar com IA: as redes neurais são boas em encontrar tipos de vulnerabilidades como IDOR (acesso não autorizado a objetos). Ao mesmo tempo, não recomendo deixar os agentes de IA se divertirem com vulnerabilidades como Docker Escape ou Privilege Escalation – com grande probabilidade, eles quebrarão algo (isso já aconteceu comigo várias vezes).

Na maioria das vezes, uso os modelos mais recentes da OpenAI, Codex e Claude, para encontrar vulnerabilidades. Na prática, funciona assim: em vez de passar horas analisando um grande volume de dados repetitivos, você recebe um resumo preliminar de vetores suspeitos e, em seguida, verifica manualmente as direções mais interessantes. Ao mesmo tempo, não diria que a IA substitui o pesquisador. Pelo contrário, ela acelera significativamente a parte rotineira do trabalho. A validação final, a compreensão da criticidade da vulnerabilidade e a demonstração da exploração do ataque ainda permanecem com o ser humano.

Falsos positivos e relatórios de IA

Apesar de todas as suas vantagens, as redes neurais podem gerar falsos positivos e resultados incorretos. Por exemplo, as versões atuais dos modelos não possuem um filtro de criticidade. Embora eu tenha conseguido, através de prompts, fazer com que o modelo não retorne respostas de erro 500 do servidor ou vazamentos de análise como bugs perigosos, ainda está longe do ideal.

Como distinguir o falso do verdadeiro? Apenas com a prática: envie relatórios para os programas e, com o tempo, entenda quais empresas aceitam quais vulnerabilidades.

Muitos reclamam que a qualidade dos relatórios piorou devido à IA. Para que seu relatório não se perca e seja válido, é importante demonstrar a reprodução da vulnerabilidade com o máximo de detalhes possível. Em muitos casos, capturas de tela detalhadas com demonstração passo a passo do ataque e seu resultado são suficientes. Às vezes, os proprietários de programas de bug bounty também solicitam uma demonstração em vídeo da exploração da vulnerabilidade encontrada. Essa abordagem também ajuda as empresas a garantir que não se trata do resultado do trabalho de uma rede neural, mas de um relatório válido de um pesquisador.

Análise de um caso de um milhão e meio de reais

Durante minha participação em programas de bug bounty, encontrei vulnerabilidades de todos os níveis, de baixo a crítico. Vou contar sobre um caso divertido e um dos mais lucrativos, onde consegui desvendar uma bela cadeia de exploração.

A história começou com uma análise comum de APK de um aplicativo móvel. O aplicativo possuía um serviço de processamento de imagens: o cliente enviava um link para uma imagem, o servidor a baixava, processava e retornava o resultado. Para evitar que fossem enviados links arbitrários para o serviço, as requisições eram assinadas via HMAC.

O problema era que a chave para essa assinatura estava diretamente no código do aplicativo. Ou seja, o esquema de proteção era assim: o aplicativo cria a assinatura → a chave é armazenada dentro do aplicativo → o servidor confia nessa assinatura. Isso significa que, se você descompilar o APK, poderá obter a chave e gerar assinaturas por conta própria para quaisquer URLs. Rapidamente escrevi um pequeno script que inseria qualquer endereço e gerava um link válido para ele.

Em seguida, descobri outro detalhe importante. O serviço tinha um parâmetro raw. No modo normal, o servidor esperava que o link contivesse uma imagem. Mas no modo raw, ele simplesmente retornava a resposta como está, sem verificar o tipo de conteúdo. Através disso, o dispositivo final poderia receber páginas HTML, respostas JSON, APIs internas e qualquer conteúdo ao qual o servidor pudesse acessar. Na prática, isso era uma SSRF – uma vulnerabilidade na qual um invasor força o servidor de um aplicativo vulnerável a enviar requisições HTTP arbitrárias em seu nome (escrevemos sobre isso aqui: Onde e como procurar essa sua SSRF: primeiros passos no bug hunting).

A próxima pergunta era a mais importante: esse serviço tinha acesso à rede interna da empresa? Verifiquei isso de forma bastante simples. Tentei acessar o endereço interno do painel administrativo, que não abria de forma alguma pela internet. Conectar-se diretamente a ele era impossível, mas através do serviço vulnerável, o servidor retornou tranquilamente o HTML da página interna. Ficou claro que o processador de imagens tinha acesso à infraestrutura interna da empresa.

Depois disso, a cadeia começou a se desenrolar. Primeiro, consegui obter arquivos de configuração. Depois, o source map do frontend, a partir do qual pude reconstruir a estrutura das APIs internas. No final, encontrei um dispositivo final através do qual os dados dos usuários eram descarregados página por página: nomes, telefones, endereços de e-mail. Em cada etapa, verifiquei separadamente que esses dados realmente não estavam acessíveis externamente e só abriam através da rede interna. Isso era importante para confirmar a vulnerabilidade. O resultado – um vetor perigoso totalmente confirmado e um pagamento de 1.500.000 rublos por um único relatório.

E agora?

No momento, estou buscando vulnerabilidades apenas no Standoff Bug Bounty. Gosto de trabalhar com essa plataforma, onde, além disso, já tenho muitos programas privados abertos.

Entre os objetivos mais próximos, está a conclusão de um evento inadmissível no âmbito de um teste de cibersegurança em uma empresa. Há muito tempo estou perto desse cenário: periodicamente parece que falta pouco para uma cadeia de exploração completa, mas algo ainda não se encaixa.

Falando de forma global, meu objetivo principal agora é passar nos exames e conseguir uma oferta incrível de uma empresa na área de segurança da informação. O bug bounty oferece uma prática muito poderosa e uma excelente experiência, mas com o tempo, gostaria de me mover também para a pesquisa corporativa séria, já dentro de uma equipe forte e em projetos grandes.