🌟 Atualização imperdível para quem gosta de estar bem informado!
Confira agora e compartilhe com seus amigos!
Apoie esse projeto de divulgacao de noticias! Clique aqui
A IA está mudando a forma como a pesquisa de vulnerabilidades é feita, mas a maior parte da conversa ainda é teórica: o que um modelo pode eventualmente ser capaz, em vez do que ele pode realmente encontrar hoje.
Queríamos responder a uma questão mais prática: usando os modelos já disponíveis para nós neste momento, até onde a IA pode nos levar na descoberta de vulnerabilidades reais e exploráveis em software de produção?
Este artigo detalha como a equipe da Intruder está usando LLMs para encontrar novas vulnerabilidades usando estruturas de varredura de código junto com modelos atuais pré-Mythos.
Percorremos um dia zero de injeção SQL remota e de vários estágios que descobrimos em um plug-in do WordPress com mais de 300.000 usuários - totalmente automatizado desde a descoberta até a exploração, sem nenhum humano no circuito.
O problema do foco: por que apontar a IA para uma base de código inteira não funciona
O grande problema ao combinar IA com um scanner de código é o foco. LLMs são excelentes para pegar pequenos segmentos de código ou uma descrição de um problema específico e encontrar uma solução interessante. Mas aponte um para uma grande base de código e peça para encontrar problemas de segurança, e ele tentará ingerir todos os arquivos do repositório.
Isso é caro em tokens e pior em termos de precisão: quando o modelo está na metade, seu contexto está cheio de código irrelevante e o bug que você realmente deseja está enterrado em ruído.
Para bugs mais complexos que exigem o encadeamento de várias etapas, você depende da estrutura para manter o contexto correto na memória ou recuperá-lo de forma inteligente quando necessário. Em nossa experiência, isso produz resultados ruins em vez de bugs reais e interessantes.
As estruturas tradicionais de digitalização de código já resolvem isso. Usamos uma técnica que chamamos de fatia de programa, que é semelhante a quando uma ferramenta IDE ou LSP usa recursos como "encontrar implementação" ou um gráfico de chamada para encontrar todas as funções chamadas pela função atual. Essas são ferramentas maduras e bem testadas e evitam totalmente o problema do contexto diluído.
Pentest com todos os principais lançamentos. Segurança que acompanha a engenharia.
Os agentes de pentesting de IA da Intruder oferecem a profundidade de um envolvimento manual sob demanda: sem lead time, sem chamadas de escopo, por uma fração do custo.
Teste cada versão, feche sua janela de exposição e obtenha um relatório pronto para auditoria em horas.
Agende uma demonstração
Nosso pipeline: da base de código ao exploit funcional
Construímos um pipeline que pega uma base de código, executa-a por meio de um mecanismo de varredura de código (usamos Joern), gera fatias de código relevantes para cada descoberta e usa um LLM para fazer a triagem e explorar o problema. O design foi inspirado no trabalho do nooperator no Slice, embora usemos Joern em vez de CodeQL e tenhamos projetado o algoritmo de fatiamento de maneira bem diferente para lidar com as classes de vulnerabilidade específicas que procuramos.
Nós apontamos isso para os 200 principais plug-ins do WordPress – código que já foi bastante escolhido por pesquisadores de recompensas de bugs, portanto, encontrar algo real lá significaria que o processo pode competir com humanos qualificados.
Primeiro, Joern é executado na base de código com regras projetadas para sinalizar padrões amplamente "interessantes" — isso é deliberadamente solto para evitar a criação de regras que sejam muito específicas e possam perder bugs. Como o agente de triagem filtra mais tarde de qualquer maneira, podemos errar no lado dos falsos positivos.
Para este experimento, buscamos uma superfície de ataque de plug-in WordPress não autenticado, então pedimos a Joern que identificasse todos os lugares em que um script pode ser afetado pela entrada do usuário: rotas REST, ganchos de modelo, chamadas AJAX nopriv e assim por diante.
Para cada gancho do WordPress, Joern gera uma fatia: a função que o gancho chama, cada método que a função chama e assim por diante na cadeia. O rastreamento básico de contaminação exclui funções obviamente seguras, como entradas SQL e XSS que passam por um desinfetante conhecido como seguro. Onde podemos verificar estaticamente se o código é seguro para execução, descartamos aqueles que passam para um LLM.
Cada fatia vai para um modelo de triagem leve (Sonnet, em nossos testes) para filtrar o que é obviamente desinteressante: ganchos que devem ser públicos e não têm efeitos colaterais, por exemplo.
O que resta vai para um modelo mais pesado (Opus) para avaliar a explorabilidade, com todo o contexto de chamada relevante na memória, para que não seja caçado em fontes não relacionadas.
Qualquer coisa considerada explorável vai para um agente de exploração final para tentar escrever uma exploração. Este agente tem acesso ao código-fonte completo novamente (se necessário), pois agora pode usar pesquisas direcionadas para encontrar código relevante e também irá ativar um contêiner Docker executando o software para testar durante o desenvolvimento.
A primeira vulnerabilidade: uma injeção cega de SQL em um plugin popular do WordPress
O primeiro bug vendido pelo pipeline foi CVE-2026-3985, uma vulnerabilidade de injeção de SQL no plugin Creative Mail. Ele se destacou para nós por alguns motivos:
É de alto impacto, dando ao invasor acesso de leitura ao banco de dados (incluindo hashes de administrador e tokens secretos!)
Requer vários c
Queríamos responder a uma questão mais prática: usando os modelos já disponíveis para nós neste momento, até onde a IA pode nos levar na descoberta de vulnerabilidades reais e exploráveis em software de produção?
Este artigo detalha como a equipe da Intruder está usando LLMs para encontrar novas vulnerabilidades usando estruturas de varredura de código junto com modelos atuais pré-Mythos.
Percorremos um dia zero de injeção SQL remota e de vários estágios que descobrimos em um plug-in do WordPress com mais de 300.000 usuários - totalmente automatizado desde a descoberta até a exploração, sem nenhum humano no circuito.
O problema do foco: por que apontar a IA para uma base de código inteira não funciona
O grande problema ao combinar IA com um scanner de código é o foco. LLMs são excelentes para pegar pequenos segmentos de código ou uma descrição de um problema específico e encontrar uma solução interessante. Mas aponte um para uma grande base de código e peça para encontrar problemas de segurança, e ele tentará ingerir todos os arquivos do repositório.
Isso é caro em tokens e pior em termos de precisão: quando o modelo está na metade, seu contexto está cheio de código irrelevante e o bug que você realmente deseja está enterrado em ruído.
Para bugs mais complexos que exigem o encadeamento de várias etapas, você depende da estrutura para manter o contexto correto na memória ou recuperá-lo de forma inteligente quando necessário. Em nossa experiência, isso produz resultados ruins em vez de bugs reais e interessantes.
As estruturas tradicionais de digitalização de código já resolvem isso. Usamos uma técnica que chamamos de fatia de programa, que é semelhante a quando uma ferramenta IDE ou LSP usa recursos como "encontrar implementação" ou um gráfico de chamada para encontrar todas as funções chamadas pela função atual. Essas são ferramentas maduras e bem testadas e evitam totalmente o problema do contexto diluído.
Pentest com todos os principais lançamentos. Segurança que acompanha a engenharia.
Os agentes de pentesting de IA da Intruder oferecem a profundidade de um envolvimento manual sob demanda: sem lead time, sem chamadas de escopo, por uma fração do custo.
Teste cada versão, feche sua janela de exposição e obtenha um relatório pronto para auditoria em horas.
Agende uma demonstração
Nosso pipeline: da base de código ao exploit funcional
Construímos um pipeline que pega uma base de código, executa-a por meio de um mecanismo de varredura de código (usamos Joern), gera fatias de código relevantes para cada descoberta e usa um LLM para fazer a triagem e explorar o problema. O design foi inspirado no trabalho do nooperator no Slice, embora usemos Joern em vez de CodeQL e tenhamos projetado o algoritmo de fatiamento de maneira bem diferente para lidar com as classes de vulnerabilidade específicas que procuramos.
Nós apontamos isso para os 200 principais plug-ins do WordPress – código que já foi bastante escolhido por pesquisadores de recompensas de bugs, portanto, encontrar algo real lá significaria que o processo pode competir com humanos qualificados.
Primeiro, Joern é executado na base de código com regras projetadas para sinalizar padrões amplamente "interessantes" — isso é deliberadamente solto para evitar a criação de regras que sejam muito específicas e possam perder bugs. Como o agente de triagem filtra mais tarde de qualquer maneira, podemos errar no lado dos falsos positivos.
Para este experimento, buscamos uma superfície de ataque de plug-in WordPress não autenticado, então pedimos a Joern que identificasse todos os lugares em que um script pode ser afetado pela entrada do usuário: rotas REST, ganchos de modelo, chamadas AJAX nopriv e assim por diante.
Para cada gancho do WordPress, Joern gera uma fatia: a função que o gancho chama, cada método que a função chama e assim por diante na cadeia. O rastreamento básico de contaminação exclui funções obviamente seguras, como entradas SQL e XSS que passam por um desinfetante conhecido como seguro. Onde podemos verificar estaticamente se o código é seguro para execução, descartamos aqueles que passam para um LLM.
Cada fatia vai para um modelo de triagem leve (Sonnet, em nossos testes) para filtrar o que é obviamente desinteressante: ganchos que devem ser públicos e não têm efeitos colaterais, por exemplo.
O que resta vai para um modelo mais pesado (Opus) para avaliar a explorabilidade, com todo o contexto de chamada relevante na memória, para que não seja caçado em fontes não relacionadas.
Qualquer coisa considerada explorável vai para um agente de exploração final para tentar escrever uma exploração. Este agente tem acesso ao código-fonte completo novamente (se necessário), pois agora pode usar pesquisas direcionadas para encontrar código relevante e também irá ativar um contêiner Docker executando o software para testar durante o desenvolvimento.
A primeira vulnerabilidade: uma injeção cega de SQL em um plugin popular do WordPress
O primeiro bug vendido pelo pipeline foi CVE-2026-3985, uma vulnerabilidade de injeção de SQL no plugin Creative Mail. Ele se destacou para nós por alguns motivos:
É de alto impacto, dando ao invasor acesso de leitura ao banco de dados (incluindo hashes de administrador e tokens secretos!)
Requer vários c
#samirnews #samir #news #boletimtec #construímos #uma #máquina #de #venda #automática #de #vulnerabilidades: #entrada #de #tokens #de #ia, #saída #de #dia #zero
🚀 Mais conteúdos incríveis estão por vir, fique atento!
Postar um comentário