GuardBreaker tenta manipular modelos de IA para travar análise de malware

A Eset identificou uma técnica de evasão que procura explorar os mecanismos de segurança dos Large Language Models (LLM) para interromper a análise de malware. Denominada GuardBreaker, a técnica foi encontrada num VBScript utilizado pelo grupo UAC-0099 nas fases iniciais de um ataque contra um alvo na Ucrânia.

O grupo, que a Eset descreve como alinhado com a Rússia, introduziu no código um comentário contendo um pedido fictício de instruções para construir uma arma nuclear. O objetivo aparente seria fazer com que um modelo de IA recusasse continuar a responder por motivos de segurança, interrompendo a análise antes de chegar ao código malicioso.

O comentário não interfere com a execução do VBScript. É dirigido ao eventual sistema de IA responsável por analisar o ficheiro, mostrando como os atacantes começam a adaptar técnicas de evasão à utilização de modelos de linguagem nos processos de cibersegurança.

A Eset salienta, contudo, que a investigação demonstra a tentativa de manipulação, mas não que uma ferramenta específica tenha efetivamente interrompido a análise ou classificado o ficheiro como seguro.

O GuardBreaker funciona como uma forma de Prompt Injection. Em vez de o atacante introduzir diretamente uma instrução numa aplicação de IA, o conteúdo é colocado no ficheiro que posteriormente poderá ser submetido ao modelo para análise. A técnica explora a dificuldade dos LLM em distinguir de forma consistente entre as instruções que devem seguir e o conteúdo não fidedigno que devem apenas analisar.

Neste caso, o VBScript tinha como finalidade descarregar e instalar o MATCHBOIL, um loader utilizado pelo UAC-0099 para distribuir outros componentes maliciosos. A Eset enquadra o GuardBreaker num conjunto mais amplo de tentativas para interferir com analisadores baseados em LLM. Entre as técnicas já observadas encontram-se instruções inseridas em pacotes maliciosos para levar o modelo a ignorar código perigoso ou classificá-lo como seguro.

Outra abordagem passa por introduzir grandes quantidades de texto repetido para ocupar a janela de contexto do modelo e reduzir a capacidade de analisar o código apresentado posteriormente.

A eficácia deste tipo de ataque depende também da forma como os sistemas tratam uma resposta incompleta do modelo. Uma recusa em continuar uma análise não equivale à ausência de uma Ameaça.

O risco aumenta quando uma plataforma automatizada não distingue entre um resultado que indica que não foi encontrado Malware e uma análise que não chegou a ser concluída. Em processos como revisão automática de código ou avaliação de dependências de Software, esta diferença pode determinar se são ou não acionadas verificações adicionais.

“A análise interrompida ou inconclusiva deve desencadear verificações adicionais”, afirma Nuno Mendes, diretor-geral da Eset Portugal, defendendo a combinação de diferentes camadas de proteção, investigação de Ameaças e avaliação humana.

A Eset recomenda que os modelos de linguagem não tenham, isoladamente, autoridade para determinar que um ficheiro é seguro. As organizações devem combinar os resultados destes sistemas com outros métodos de análise e estabelecer procedimentos específicos para situações em que a ferramenta recusa responder, processa apenas parte do conteúdo ou não consegue concluir a análise.