Combater fogo com fogo: usando IA para combater IA

Os ataques a aplicativos aumentaram drasticamente. 83% em janeiro de 2025, contra 65% anteriormente. apenas um ano antes. Esse número por si só já deveria fazer qualquer equipe de segurança refletir — mas a questão mais importante é por que a curva está subindo tão acentuadamente. A resposta não é que de repente haja mais atacantes. É que cada atacante é mais capaz do que antes, e a diferença entre um novato e um especialista diminuiu de maneiras que deveriam preocupar qualquer pessoa responsável por entregar aplicativos aos clientes. 

Os grandes modelos de linguagem fizeram isso. Não gradualmente, e não de forma marginal. Eles reduziram os requisitos de habilidade e tempo para atacar uma aplicação da mesma forma que reduziram os requisitos de habilidade e tempo para criá-la. As ferramentas (jadx, IDAPro, Ghidra, Frida) já existiam, e outras circulam há anos. O que mudou foi a expertise necessária para usá-las com eficácia e a velocidade com que um atacante motivado pode passar da identificação do alvo à exploração ativa. 

Um colega, Cole Herzog, publicou uma análise técnica detalhada exatamente dessa dinâmica (Hacking com Inteligência Artificial, ou: Como Aprender a Parar de se Preocupar e Amar o LLME vale a pena ler na íntegra, caso ainda não o tenha feito. Cole demonstra, passo a passo, como um atacante usa um LLM para fazer engenharia reversa de um binário de aplicativo móvel, configurar um ambiente de instrumentação dinâmica e enumerar funções dentro de um aplicativo em execução. Nenhuma das etapas individuais é nova. A novidade está na pouca experiência que cada etapa agora exige. 

A tradução para o mundo dos negócios é simples: quem não tinha as habilidades para executar esse ataque há doze meses provavelmente as tem agora, ou tem acesso a uma ferramenta que supre essa necessidade. A demonstração de Cole usou um simples dump hexadecimal inserido em um LLM (Language Link-Memory) disponível publicamente para extrair endpoints de API de um binário desprotegido em menos de dois minutos. Isso não é um ataque sofisticado. É um projeto para uma tarde e é o primeiro passo em uma cadeia que termina nos seus sistemas de back-end. 

O motivo pelo qual os aplicativos do lado do cliente ocupam uma posição única nesse cenário de ameaças se resume a: assimetria fundamental que nenhuma medida de segurança de rede resolve. Seus servidores estão protegidos por firewalls, camadas de autenticação e controles de acesso que você possui e opera. Seu aplicativo móvel está em um dispositivo que você não possui, em um ambiente que você não controla, executando um código que qualquer pessoa no mundo pode baixar, descompactar e inspecionar. O código do lado do cliente é totalmente acessível e legível por agentes maliciosos. Não estamos falando de um problema de configuração ou de uma falha na aplicação de patches. É a natureza do meio. 

Essa assimetria sempre existiu. Considere um banco com dois milhões de usuários ativos mensais. Estatisticamente, uma parcela desses usuários sempre incluiu pessoas curiosas sobre o conteúdo do aplicativo — e uma parcela menor dessas sempre incluiu pessoas dispostas a agir com base no que descobriram. Essa ameaça existia em 2022, em 2021 e muito antes disso. O que os LLMs introduziram foi um multiplicador de força em ambas as extremidades do espectro de ataques. O atacante que passava semanas fazendo engenharia reversa de um binário em 2023 agora pode fazer o mesmo em horas. E o usuário curioso que teria se deparado com a complexidade técnica e desistido agora tem uma ferramenta que o guia por cada etapa, escreve os scripts e explica a saída — até o ponto em que um projeto paralelo deixa de ser mera curiosidade e se torna algo mais deliberado. O grupo de pessoas capazes de realizar um ataque significativo do lado do cliente acaba de aumentar consideravelmente. 

Eis o que torna os ataques do lado do cliente particularmente difíceis de combater: eles não se parecem com ataques. Um invasor que realiza engenharia reversa do seu aplicativo, extrai uma chave de API válida e começa a consultar seu servidor de back-end gera um tráfego indistinguível do tráfego legítimo. A chave é real. A autenticação é bem-sucedida. As requisições seguem os padrões esperados. Não há alarme, nenhuma anomalia, nenhum sinal óbvio de que algo deu errado porque, da perspectiva da sua infraestrutura, nada deu errado. A sessão parece exatamente como a de um dos seus dois milhões de usuários legítimos. 

É por isso que o volume de violações de segurança do lado do cliente documentadas publicamente subestima a frequência real de ataques desse tipo. A violação que é relatada é aquela que causa uma interrupção, dispara um alerta de fraude ou aparece em um relatório regulatório. O invasor que age com cautela, coleta dados gradualmente e usa credenciais legítimas pode nunca aparecer em um relatório de incidente. A ausência de evidências não é evidência de ausência — é evidência de uma falha no monitoramento. 

Monitoramento de ameaças em tempo de execução Preenche essa lacuna. Saber que um aplicativo está sendo executado em um ambiente comprometido, que seu código foi adulterado ou que suas proteções estão sendo testadas — essa informação existe no momento em que acontece, não depois que o dano já foi feito. Mas a detecção por si só não é tudo. A capacidade mais poderosa é a reação: Respostas codificadas diretamente no binário do aplicativo que são acionadas automaticamente quando condições específicas de ameaça são atendidas.Um aplicativo bancário que detecta adulteração pode forçar a autenticação em duas etapas antes que o invasor consiga ir mais longe. Um aplicativo em execução em um ambiente comprometido pode se encerrar completamente. Um jogo para celular que detecta uma ferramenta de trapaça pode responder com algo mais criativo — desativando a gravidade para as unidades daquele jogador, por exemplo, para que seus soldados flutuem silenciosamente para fora do campo de batalha enquanto os jogadores legítimos nem percebem nada. O invasor sofre as consequências. A experiência de todos os outros permanece intacta. 

A resposta lógica a uma ameaça que se acelera é acelerar a defesa na mesma proporção. Isso é mais fácil dizer do que fazer quando a criação de um Plano de Proteção (a configuração que determina exatamente como um aplicativo é reforçado) exige semanas de discussões entre engenheiros de segurança, engenheiros de vendas e, em alguns casos, os próprios desenvolvedores do aplicativo. Durante esse período, o aplicativo é lançado sem proteção completa ou o cronograma de lançamento atrasa. Nenhum dos dois resultados é aceitável quando o cenário de ameaças está evoluindo tão rapidamente quanto agora, e atrasos nos cronogramas de lançamento significam lucros atrasados. 

É aqui que a IA na área da defesa entra na conversa — não como um conceito de marketing, mas como uma resposta prática a um problema operacional real. Agente de Proteção Rápida v2 Analisa o código do aplicativo, determina quais componentes precisam de maior proteção e gera automaticamente um primeiro rascunho personalizado do Plano de Proteção. O que antes levava cerca de duas semanas de trabalho colaborativo de engenharia agora leva aproximadamente duas horas. Essa compressão é importante não apenas para a eficiência, mas também para a segurança: quanto mais rápido a proteção puder ser configurada e implementada, menor será o período em que um aplicativo fica exposto. 

A postagem de Cole levanta um ponto importante que vale a pena destacar aqui. Os LLMs só podem trabalhar com as informações disponíveis para eles — o que significa que podem auxiliar atacantes na engenharia reversa de ferramentas cujas implementações são de conhecimento público, mas têm dificuldades contra proteções para as quais não foram treinados. O fortalecimento baseado em propriedade intelectual cria uma lacuna que as ferramentas de código aberto não criam. A defesa que age rapidamente, aplica proteção que não é publicamente legível para um LLM e consegue detectar e reagir a ataques em tempo real é um alvo significativamente mais difícil do que uma que não o faz. 

Outro ponto importante a considerar é que nenhuma ferramenta de segurança pode ser considerada definitiva. O cenário de ameaças continuará a evoluir. Todos os fornecedores de segurança dependem de equipes de pesquisa de ameaças para se manterem atualizados. Digital.ai Não é diferente, e nossa equipe de Pesquisa de Ameaças está distribuída por dois continentes, garantindo que nosso Fortalecimento de Aplicativos continue a evoluir conforme as ameaças evoluem. 

The 2025 Application Security Relatório de Ameaça Os documentos mostram uma taxa de ataques que vem aumentando acentuadamente e não apresenta sinais de estabilização. A dinâmica subjacente que impulsiona essa curva não vai se inverter — as ferramentas existem, estão sendo aprimoradas e são acessíveis a qualquer pessoa motivada o suficiente para usá-las. Esse é o ambiente em que seus aplicativos operam hoje, e será ainda mais evidente daqui a um ano. 

Nada disso justifica pânico. Pelo contrário, justifica honestidade sobre qual é a ameaça de fato, onde ela se encontra e o que é necessário para combatê-la seriamente. A superfície de ataque do lado do cliente não vai desaparecer só porque você atualizou seus servidores ou reforçou o perímetro da sua rede. O invasor que baixou seu aplicativo, forneceu o binário a um LLM e começou a mapear seus caminhos de back-end não tocou na sua infraestrutura. Ele não precisou. 

A boa notícia é que a mesma tecnologia que acelera o ataque está disponível na defesa, e os fundamentos do que torna um aplicativo difícil de atacar não mudaram: ofuscação para a qual um LLM não foi treinado; proteções em tempo de execução que detectam e reagem antes que o dano seja causado; reforço de segurança configurado precisamente para o aplicativo específico, em vez de aplicado genericamente; e velocidade de implantação que acompanha a velocidade da ameaça. Essas não são ideias novas. O que é novo é a urgência de aplicá-las bem.