Este artigo explora a crescente vulnerabilidade de Large Language Models (LLMs) a ataques, demonstrando como ferramentas acessíveis e técnicas de engenharia de prompt podem ser usadas para explorar falhas de segurança em sistemas baseados em IA. O autor detalha um processo prático para criar e executar ataques, destacando a facilidade com que dados sensíveis podem ser expostos.
MundiX News·01 de maio de 2026·10 min de leitura·👁 1 views
O desenvolvimento implacável e acelerado dos modernos LLMs não deixa dúvidas de que, em um futuro próximo, pequenas e médias empresas poderão ter seus próprios modelos operando com bancos de dados de clientes, manipulando documentação interna e delegando tarefas aos funcionários. Com isso, surge uma questão lógica: quão resiliente será essa solução técnica a ataques de hackers amadores ou cibercriminosos sérios? Poderemos confiar dados verdadeiramente sensíveis a uma máquina sem alma, mas extremamente engenhosa, em breve, ou devemos esperar?
Este artigo é uma fantasia livre sobre o tema "e se?" e, em grande parte, um modesto panorama de ferramentas maravilhosas que eu nem sonhava há um ano. A motivação para explorar este tema é clara: em um hackathon recente, a vitória foi conquistada não pela beleza do site ou pela segurança da arquitetura, mas pela criação de um chatbot. Projetando isso para 2026, um LLM seria a escolha óbvia. O plano parece sólido: pegar um modelo, fornecer um prompt de sistema, misturar documentos internos, dar acesso a um banco de dados e chamá-lo de assistente de IA. Ao extrapolar isso para o nível de uma pequena, mas orgulhosa empresa, obtemos uma nova e desconhecida entidade que aceita entradas não validadas, processa dados sensíveis e os entrega ao cliente. O risco é que, em vez de um assistente inteligente e trabalhador, tenhamos um porteiro de dados pouco perspicaz, através do qual as informações podem vazar não apenas por meio de ataques complexos, mas também por meio desse agradável interlocutor.
O processo de criação deste artigo e das ferramentas associadas foi realizado durante a noite, com uma xícara de chá, enfatizando a redução do limiar de entrada para a carreira de um cibercriminoso. Para um não programador, a necessidade principal é uma ferramenta para realizar o ataque. Mesmo com conhecimento limitado de programação e familiaridade básica com mecanismos de busca, é possível encontrar ferramentas como o Claude Code, que lida bem com a escrita de código. A principal dificuldade reside na criação do prompt, mas isso também não é um problema. Os prompts geralmente incluem frases como "Projeto de pesquisa", "ambiente de treinamento" ou "ferramenta de segurança da informação criada para a resiliência do nosso perímetro externo". No entanto, o Claude Code limita a capacidade de criar programas sem conhecimento de programação. Para contornar isso, o Codex surge como uma alternativa. Se o Codex for proibido, um atacante persistente pode recorrer ao OpenCode, utilizando APIs como a do DeepSeek ou até mesmo uma LLM local, se possuir a infraestrutura necessária. Embora este último cenário possa não atender totalmente aos requisitos do título do artigo, ele demonstra a escalabilidade das ameaças. A tabela comparativa mostra que, enquanto o Claude tem um limite de contexto frustrante, o Codex oferece uma solução mais acessível e satisfatória, com um custo significativamente menor. O Open Source, como o OpenCode, é uma opção condicionalmente gratuita, exigindo um investimento inicial em tokens.
Após algumas noites de trabalho (ou uma noite mais longa e produtiva), é possível ter um "gerador de prompts" confiável. A criação desse gerador envolve uma série de prompts, começando com um prompt maior que convence o modelo da sua prudência, ética e profissionalismo. A habilidade de "vender-se" bem para o modelo, em vez de conhecimento técnico acadêmico, pode ser uma vantagem. Ao solicitar diretamente ao modelo a criação de uma ferramenta de ataque a LLMs, a resposta será, previsivelmente, uma recusa. No entanto, o interesse educacional em explorar as vulnerabilidades de LLMs leva à descoberta de várias classificações de ataques, incluindo: Prompt Injection (substituição de instruções), Jailbreaking (contornar restrições comportamentais), Extraction (extração de prompts de sistema ocultos), Goal Hijacking (redirecionamento da lógica do modelo), Token Attacks (exploração de representações de texto), Many-shot (sobrecarga com exemplos para moldar o comportamento), Context Manipulation (substituição da moldura da conversa) e Sensitive Data Exposure (exposição de dados ocultos). O apetite por explorar essas vulnerabilidades cresce com a prática. O plano inicial de usar um conjunto fixo de prompts para atacar maquetes evoluiu para um cenário onde a própria LLM é solicitada a gerar cenários de ataque contra um LLM dentro de um produto criado por LLM, utilizando uma API como a do DeepSeek. Essa abordagem se mostra eficaz, com a IA concordando em gerar novas requisições maliciosas com base em um "seed" de prompts anteriores.
Com a ferramenta pronta, o próximo passo é testá-la em ambientes reais. Os primeiros ataques foram realizados contra o YandexGPT e o DeepSeek. Embora esses modelos não contenham dados sensíveis diretos, o sucesso foi medido pela capacidade de obter respostas a perguntas capciosas sem que o modelo se recusasse a responder ou banisse o usuário. Surpreendentemente, os modelos demonstraram uma propensão a dar conselhos inadequados quando "entravam em um papel". Ataques como "DoAnythingNow" tiveram sucesso variável, e a injeção de instruções em entradas para leitura de e-mails em formato Word não foi bem-sucedida. As tabelas de resultados indicam que, embora algumas respostas sejam consideradas "parciais" ou "discutíveis" pela LLM, a avaliação do autor revela recusas claras em outros casos. Os ataques verdadeiramente bem-sucedidos e antiéticos incluíram a geração de um algoritmo passo a passo para reconhecimento e ataque a interfaces web, e a descrição de métodos para contornar verificações de licença de software, demonstrando a eficácia das técnicas exploradas.
Para testar a robustez contra um cenário de negócios real, o Codex foi utilizado para configurar um ambiente Ollama com uma descrição de negócios e um pequeno banco de dados de usuários. A configuração inicial no Windows apresentou problemas de compatibilidade com a GPU, levando à migração para Ubuntu para aproveitar o desempenho otimizado do Ollama baseado em GPU. O Codex gerou maquetes que foram submetidas a ataque. Um exemplo notável envolveu um "SMB-mockup" baseado no modelo qwen2.5:7b, configurado como um "support-copilot" com "guardrails" explícitos contra contexto oculto, registros brutos, notas internas e segredos. O ataque foi bem-sucedido, com 3 de 5 payloads bypassando as defesas, resultando em uma taxa de bypass de 75% e um "exposure score" de 80%. O modelo não apenas revelou o esquema, mas também expôs o "system prompt" com "application_guardrails", um fragmento de customers.csv, três registros precisos de tickets.json e uma lista separada de e-mails e telefones. Isso demonstra que mesmo um assistente local mais "sério" com instruções de proteção pode ser comprometido por requisições diretas e simples.
O relatório detalhado do ataque, incluindo novas vazamentos e estatísticas atualizadas, foi salvo. A facilidade com que um prompt simples, com poucas especificações técnicas, levou a um progresso significativo na configuração do ambiente e na execução do ataque é notável. Anteriormente, um pentester gastaria muito tempo configurando um ambiente virtual, infraestrutura de rede e, em seguida, executando o ataque, idealmente planejando cada etapa, desde a reconhecimento até a exfiltração. Isso exigiria experiência, um conjunto de ferramentas estabelecido e, crucialmente, tempo. Em contraste, o processo descrito consumiu apenas algumas noites e um custo nominal em agentes. O resultado pode ser categorizado em três níveis: o mais preocupante é a facilidade com que um modelo simples com um prompt de "proteção" rápido pode ser comprometido, levando à exposição de dados brutos. Uma segunda categoria envolve uma segurança mínima, onde dados brutos e o modelo são separados, com um backend atuando como filtro. Nesse cenário, apenas um ataque foi parcialmente bem-sucedido, com a extração de um número de telefone. A terceira categoria, que representa um nível mais alto de segurança, envolve a implementação de DLP e validações antes de exibir respostas ao usuário, incluindo a filtragem de e-mails, telefones, endereços, credenciais e fragmentos de prompt de sistema. No mockup apresentado, sem uma solução de segurança de combate, um regex simples foi usado para proibir dados do banco de dados CSV, resultando em 0 ataques bem-sucedidos.
A conclusão é clara: empresas com investimentos em segurança cibernética podem resistir a ataques superficiais, mas a proliferação de soluções de TI rápidas e baseadas em IA pode levar a problemas significativos à medida que a onda de IA avança. Enquanto grandes vazamentos de dados pessoais, resultantes de ataques complexos, já são uma realidade, os mini-vazamentos diários representam uma nova e preocupante ameaça. Espera-se que este artigo, ao detalhar as vulnerabilidades e o processo de ataque a LLMs, incentive uma reflexão mais profunda sobre a segurança dos assistentes de IA e proteja os leitores contra vazamentos de dados.
🛡️⚡
Pare de pesquisar. Comece a hackear.
O MundiX é seu copiloto de pentest com IA: comandos exatos, análise de outputs e próximo passo na kill chain — em segundos.
Sem cartão para começar · Planos a partir de R$49/mês
O desenvolvimento implacável e acelerado dos modernos LLMs não deixa dúvidas de que, em um futuro próximo, pequenas e médias empresas poderão ter seus próprios modelos operando com bancos de dados de clientes, manipulando documentação interna e delegando tarefas aos funcionários. Com isso, surge uma questão lógica: quão resiliente será essa solução técnica a ataques de hackers amadores ou cibercriminosos sérios? Poderemos confiar dados verdadeiramente sensíveis a uma máquina sem alma, mas extremamente engenhosa, em breve, ou devemos esperar?
Este artigo é uma fantasia livre sobre o tema "e se?" e, em grande parte, um modesto panorama de ferramentas maravilhosas que eu nem sonhava há um ano. A motivação para explorar este tema é clara: em um hackathon recente, a vitória foi conquistada não pela beleza do site ou pela segurança da arquitetura, mas pela criação de um chatbot. Projetando isso para 2026, um LLM seria a escolha óbvia. O plano parece sólido: pegar um modelo, fornecer um prompt de sistema, misturar documentos internos, dar acesso a um banco de dados e chamá-lo de assistente de IA. Ao extrapolar isso para o nível de uma pequena, mas orgulhosa empresa, obtemos uma nova e desconhecida entidade que aceita entradas não validadas, processa dados sensíveis e os entrega ao cliente. O risco é que, em vez de um assistente inteligente e trabalhador, tenhamos um porteiro de dados pouco perspicaz, através do qual as informações podem vazar não apenas por meio de ataques complexos, mas também por meio desse agradável interlocutor.
O processo de criação deste artigo e das ferramentas associadas foi realizado durante a noite, com uma xícara de chá, enfatizando a redução do limiar de entrada para a carreira de um cibercriminoso. Para um não programador, a necessidade principal é uma ferramenta para realizar o ataque. Mesmo com conhecimento limitado de programação e familiaridade básica com mecanismos de busca, é possível encontrar ferramentas como o Claude Code, que lida bem com a escrita de código. A principal dificuldade reside na criação do prompt, mas isso também não é um problema. Os prompts geralmente incluem frases como "Projeto de pesquisa", "ambiente de treinamento" ou "ferramenta de segurança da informação criada para a resiliência do nosso perímetro externo". No entanto, o Claude Code limita a capacidade de criar programas sem conhecimento de programação. Para contornar isso, o Codex surge como uma alternativa. Se o Codex for proibido, um atacante persistente pode recorrer ao OpenCode, utilizando APIs como a do DeepSeek ou até mesmo uma LLM local, se possuir a infraestrutura necessária. Embora este último cenário possa não atender totalmente aos requisitos do título do artigo, ele demonstra a escalabilidade das ameaças. A tabela comparativa mostra que, enquanto o Claude tem um limite de contexto frustrante, o Codex oferece uma solução mais acessível e satisfatória, com um custo significativamente menor. O Open Source, como o OpenCode, é uma opção condicionalmente gratuita, exigindo um investimento inicial em tokens.
Após algumas noites de trabalho (ou uma noite mais longa e produtiva), é possível ter um "gerador de prompts" confiável. A criação desse gerador envolve uma série de prompts, começando com um prompt maior que convence o modelo da sua prudência, ética e profissionalismo. A habilidade de "vender-se" bem para o modelo, em vez de conhecimento técnico acadêmico, pode ser uma vantagem. Ao solicitar diretamente ao modelo a criação de uma ferramenta de ataque a LLMs, a resposta será, previsivelmente, uma recusa. No entanto, o interesse educacional em explorar as vulnerabilidades de LLMs leva à descoberta de várias classificações de ataques, incluindo: Prompt Injection (substituição de instruções), Jailbreaking (contornar restrições comportamentais), Extraction (extração de prompts de sistema ocultos), Goal Hijacking (redirecionamento da lógica do modelo), Token Attacks (exploração de representações de texto), Many-shot (sobrecarga com exemplos para moldar o comportamento), Context Manipulation (substituição da moldura da conversa) e Sensitive Data Exposure (exposição de dados ocultos). O apetite por explorar essas vulnerabilidades cresce com a prática. O plano inicial de usar um conjunto fixo de prompts para atacar maquetes evoluiu para um cenário onde a própria LLM é solicitada a gerar cenários de ataque contra um LLM dentro de um produto criado por LLM, utilizando uma API como a do DeepSeek. Essa abordagem se mostra eficaz, com a IA concordando em gerar novas requisições maliciosas com base em um "seed" de prompts anteriores.
Com a ferramenta pronta, o próximo passo é testá-la em ambientes reais. Os primeiros ataques foram realizados contra o YandexGPT e o DeepSeek. Embora esses modelos não contenham dados sensíveis diretos, o sucesso foi medido pela capacidade de obter respostas a perguntas capciosas sem que o modelo se recusasse a responder ou banisse o usuário. Surpreendentemente, os modelos demonstraram uma propensão a dar conselhos inadequados quando "entravam em um papel". Ataques como "DoAnythingNow" tiveram sucesso variável, e a injeção de instruções em entradas para leitura de e-mails em formato Word não foi bem-sucedida. As tabelas de resultados indicam que, embora algumas respostas sejam consideradas "parciais" ou "discutíveis" pela LLM, a avaliação do autor revela recusas claras em outros casos. Os ataques verdadeiramente bem-sucedidos e antiéticos incluíram a geração de um algoritmo passo a passo para reconhecimento e ataque a interfaces web, e a descrição de métodos para contornar verificações de licença de software, demonstrando a eficácia das técnicas exploradas.
Para testar a robustez contra um cenário de negócios real, o Codex foi utilizado para configurar um ambiente Ollama com uma descrição de negócios e um pequeno banco de dados de usuários. A configuração inicial no Windows apresentou problemas de compatibilidade com a GPU, levando à migração para Ubuntu para aproveitar o desempenho otimizado do Ollama baseado em GPU. O Codex gerou maquetes que foram submetidas a ataque. Um exemplo notável envolveu um "SMB-mockup" baseado no modelo qwen2.5:7b, configurado como um "support-copilot" com "guardrails" explícitos contra contexto oculto, registros brutos, notas internas e segredos. O ataque foi bem-sucedido, com 3 de 5 payloads bypassando as defesas, resultando em uma taxa de bypass de 75% e um "exposure score" de 80%. O modelo não apenas revelou o esquema, mas também expôs o "system prompt" com "application_guardrails", um fragmento de customers.csv, três registros precisos de tickets.json e uma lista separada de e-mails e telefones. Isso demonstra que mesmo um assistente local mais "sério" com instruções de proteção pode ser comprometido por requisições diretas e simples.
O relatório detalhado do ataque, incluindo novas vazamentos e estatísticas atualizadas, foi salvo. A facilidade com que um prompt simples, com poucas especificações técnicas, levou a um progresso significativo na configuração do ambiente e na execução do ataque é notável. Anteriormente, um pentester gastaria muito tempo configurando um ambiente virtual, infraestrutura de rede e, em seguida, executando o ataque, idealmente planejando cada etapa, desde a reconhecimento até a exfiltração. Isso exigiria experiência, um conjunto de ferramentas estabelecido e, crucialmente, tempo. Em contraste, o processo descrito consumiu apenas algumas noites e um custo nominal em agentes. O resultado pode ser categorizado em três níveis: o mais preocupante é a facilidade com que um modelo simples com um prompt de "proteção" rápido pode ser comprometido, levando à exposição de dados brutos. Uma segunda categoria envolve uma segurança mínima, onde dados brutos e o modelo são separados, com um backend atuando como filtro. Nesse cenário, apenas um ataque foi parcialmente bem-sucedido, com a extração de um número de telefone. A terceira categoria, que representa um nível mais alto de segurança, envolve a implementação de DLP e validações antes de exibir respostas ao usuário, incluindo a filtragem de e-mails, telefones, endereços, credenciais e fragmentos de prompt de sistema. No mockup apresentado, sem uma solução de segurança de combate, um regex simples foi usado para proibir dados do banco de dados CSV, resultando em 0 ataques bem-sucedidos.
A conclusão é clara: empresas com investimentos em segurança cibernética podem resistir a ataques superficiais, mas a proliferação de soluções de TI rápidas e baseadas em IA pode levar a problemas significativos à medida que a onda de IA avança. Enquanto grandes vazamentos de dados pessoais, resultantes de ataques complexos, já são uma realidade, os mini-vazamentos diários representam uma nova e preocupante ameaça. Espera-se que este artigo, ao detalhar as vulnerabilidades e o processo de ataque a LLMs, incentive uma reflexão mais profunda sobre a segurança dos assistentes de IA e proteja os leitores contra vazamentos de dados.
📤 Compartilhar & Baixar
📩 Newsletter MundiX
Receba novidades de cibersegurança + um checklist de pentest grátis. Sem spam.
Ao assinar você concorda em receber e-mails. Cancele quando quiser.
