Protótipo de malware Skynet tenta usar prompt injection contra análise assistida por IA

A amostra combina evasão simples de sandbox, coleta de arquivos locais e um cliente Tor embutido com uma instrução textual criada para interferir em fluxos de análise que entregam código malicioso a modelos de linguagem.

Componente	Amostra de malware identificada por strings internas como Skynet, aparentemente um componente experimental ou protótipo isolado.
Vetor	Execução local do binário em ambiente Windows, com lógica de triagem que encerra a execução quando detecta condições específicas, como presença do arquivo skynet.bypass ou execução fora do diretório temporário esperado.
Impacto	Tentativa de coletar conteúdo de arquivos locais sensíveis, imprimir dados na saída padrão, instalar um cliente Tor embutido em /%TEMP%/skynet/tor.exe e criar um proxy para uso posterior.
Prioridade	Tratar a amostra como malware real apesar do comportamento incompleto, bloquear a execução, caçar artefatos de Tor em diretórios temporários, revisar exposição de chaves SSH e isolar ambientes de análise que usem LLMs com permissões operacionais.
Artefatos	Arquivos acessados incluem %HOMEPATH%\.ssh\known_hosts, C:/Windows/System32/Drivers/etc/hosts e %HOMEPATH%\.ssh\id_rsa; strings usam XOR rotativo com a chave 4sI02LaI e codificação Base64 em parte dos dados.
Mitigação	Restringir automações de análise com IA a ambientes sem acesso a shell, rede ou credenciais reais, além de validar saídas de LLM por regras determinísticas e telemetria de endpoint.

Resumo técnico

Uma amostra de malware vista em circulação pública em junho de 2025 introduz um elemento incomum no fluxo de análise: texto embutido com instruções adversariais voltadas a modelos de linguagem que possam processar o binário, código descompilado ou strings extraídas. A tentativa busca interferir no julgamento de ferramentas de análise assistidas por IA, incluindo cenários em que um LLM recebe conteúdo controlado pelo adversário e devolve um veredito sobre a natureza do arquivo. O comportamento observado não indica sucesso da técnica nos testes descritos, mas a presença do mecanismo altera o modelo de ameaça para pipelines que entregam artefatos não confiáveis a agentes de IA com autonomia excessiva.

O binário parece menos maduro do que famílias de malware completas. A execução contém rotinas incompletas, recursos preparados mas pouco utilizados e uma etapa de exfiltração que imprime dados na saída padrão em vez de transmiti-los de forma operacionalmente robusta. Ainda assim, a amostra executa ações relevantes: realiza verificações de triagem, ofusca strings, tenta ler arquivos locais com valor para reconhecimento e prepara um cliente Tor embutido para criar um proxy. A combinação de coleta local, proxy e tentativa de manipulação de análise automatizada deve ser tratada como atividade maliciosa, mesmo que a implementação pareça experimental.

Fluxo técnico

O fluxo inicial do malware inclui verificações destinadas a reduzir execução em ambientes indesejados. A amostra procura um arquivo chamado skynet.bypass; quando esse arquivo existe, a execução é encerrada. Também há uma checagem para confirmar se o binário está sendo executado a partir do diretório temporário esperado. Quando essa condição falha, a função principal retorna -101 e o processamento é interrompido. Esse tipo de triagem pode causar falso negativo em sandboxes que executam amostras a partir de caminhos padronizados fora de %TEMP%, em ambientes de análise manual que copiam o arquivo para diretórios de trabalho ou em pipelines que não reproduzem o caminho esperado pelo autor.

A amostra utiliza ofuscação de strings com XOR rotativo byte a byte e a chave embutida 4sI02LaI, seguida de Base64 em parte das strings. Algumas strings ficam em escopo global, enquanto outras são reconstruídas na pilha durante a execução, dificultando extração estática simples. O binário também inclui funções chamadas opaque_true e opaque_false, que inserem blobs de instruções assembly e retornam 0 ou 1 em al. O objetivo é complicar o fluxo de controle para ferramentas automáticas, ainda que o desenho pareça limitado. Para analistas, isso significa que o fluxo de decisão pode parecer mais ruidoso do que realmente é, mas não elimina a possibilidade de reconstruir os ramos principais por emulação, depuração controlada ou simplificação de blocos opacos.

Após passar pelas verificações, o malware tenta ler %HOMEPATH%\.ssh\known_hosts, C:/Windows/System32/Drivers/etc/hosts e %HOMEPATH%\.ssh\id_rsa. Os caminhos ligados a SSH foram codificados com barras no estilo Linux, o que reforça a impressão de protótipo ou portabilidade mal resolvida. O conteúdo coletado é impresso na saída padrão, em vez de ser enviado imediatamente a um servidor remoto. Mesmo assim, os alvos são sensíveis: id_rsa pode conter chave privada, known_hosts revela infraestrutura acessada pelo usuário e hosts pode indicar redirecionamentos locais ou ajustes de ambiente. Em seguida, um cliente Tor embutido, protegido pelo mesmo esquema de criptografia sem Base64, é descriptografado e gravado em /%TEMP%/skynet/tor.exe. A função launchTor usa CreateProcessA para iniciar o componente e configurar um proxy controlável por portas definidas no comando embutido, não detalhadas no material analisado.

A tentativa de prompt injection aparece como dado textual dentro da amostra e mira diretamente fluxos modernos de engenharia reversa, nos quais ferramentas conectam descompiladores, clientes MCP, modelos de fronteira e automações capazes de resumir funções, renomear símbolos ou executar comandos auxiliares. O objetivo do texto é desviar a tarefa do analisador e induzir uma conclusão benigna. Essa técnica não depende de explorar uma vulnerabilidade de memória; ela depende de uma falha de arquitetura no pipeline de análise: tratar conteúdo adversarial extraído de malware como instrução confiável para um modelo. Mesmo quando a tentativa falha, o evento mostra que autores de malware já consideram LLMs parte da superfície defensiva a ser enganada.

Superfície afetada

A superfície principal são estáções Windows, máquinas de análise, sandboxes e ambientes de laboratório que executem a amostra sem isolamento suficiente. A presença de %HOMEPATH% e CreateProcessA aponta para execução em Windows, enquanto os caminhos de SSH e o uso de barras inconsistentes indicam tentativa de coletar dados típicos de usuários técnicos, administradores, desenvolvedores ou operadores que mantenham chaves e histórico de conexões no perfil local. A coleta de id_rsa é especialmente crítica quando chaves privadas não têm frase de proteção forte ou quando agentes SSH, repositórios internos e servidores ainda aceitam esse material sem controles adicionais.

Outra superfície relevante são pipelines de análise de malware que incorporam GenAI. O risco aumenta quando o modelo recebe strings, código descompilado ou saídas de ferramentas como contexto sem delimitação rígida entre dados e instruções. O risco se torna mais grave quando o agente que conversa com o LLM tem permissão para executar comandos, acessar arquivos locais, consultar rede, alterar artefatos ou emitir vereditos que alimentam bloqueios e liberações automáticas. Nesses cenários, prompt injection em malware deve ser avaliada como entrada adversarial equivalente a payloads em logs, nomes de arquivos, campos de metadados e documentos maliciosos.

A criação de /%TEMP%/skynet/tor.exe amplia a superfície de rede. Mesmo que a amostra apague o diretório %TEMP%/skynet após iniciar o servidor, a execução temporária de Tor e a abertura de proxy podem deixar eventos em EDR, Sysmon, logs de criação de processo, cache de disco, artefatos de pré-busca e conexões de rede. Ambientes com política restritiva para binários escritos em diretórios temporários devem detectar esse comportamento como suspeito independentemente do nome Skynet.

• Hosts Windows que executem a amostra a partir de %TEMP% e não possuam bloqueio de execução em diretórios graváveis pelo usuário.
• Perfis de usuários com arquivos %HOMEPATH%\.ssh\id_rsa e %HOMEPATH%\.ssh\known_hosts acessíveis ao processo malicioso.
• Sandboxes e pipelines de engenharia reversa que entregam strings e código descompilado a LLMs sem separação forte entre dados não confiáveis e instruções do sistema.
• Estáções de análise que permitem a agentes de IA ou ferramentas MCP executar comandos, abrir rede ou modificar arquivos durante a investigação de amostras.

Hunting e telemetria

A caçada deve começar por eventos de processo e sistema de arquivos associados à execução em diretórios temporários. Procure criação de diretórios ou arquivos com o caminho skynet sob %TEMP%, gravação de tor.exe por processos incomuns e chamadas a CreateProcessA que iniciem Tor a partir de caminho gravável por usuário. Como o binário pode remover o diretório após a inicialização, a ordem temporal importa: eventos de curta duração, artefatos de pré-busca, trilhas de EDR e snapshots de monitoramento de arquivo podem ser mais úteis do que uma busca posterior apenas no disco.

Em endpoint, monitore leituras incomuns de %HOMEPATH%\.ssh\id_rsa, %HOMEPATH%\.ssh\known_hosts e C:/Windows/System32/Drivers/etc/hosts por processos que não sejam clientes SSH, editores, shells esperados ou ferramentas administrativas conhecidas. A leitura de chave privada por um binário recém-baixado, executado de %TEMP% ou sem assinatura confiável deve ser tratada como sinal de comprometimento de segredo. Quando houver suspeita de acesso a chave privada, a resposta não deve depender de comprovar transmissão externa; a exposição local já justifica revogação ou rotação em ambientes sensíveis.

Para ambientes que usam IA em análise de malware, a telemetria deve incluir trilhas do que foi enviado ao modelo, quais instruções de sistema foram aplicadas, quais ferramentas o agente podia acionar e se houve tentativa de execução de ações fora do escopo da análise. Texto adversarial extraído de amostras deve ser registrado como dado hostil e não como comando. Vereditos de LLM devem ser comparados com regras YARA, análise dinâmica, emulação, reputação de arquivo, observação comportamental e revisão humana quando a decisão afetar produção.

• Criação ou execução de /%TEMP%/skynet/tor.exe e diretórios temporários com o nome skynet.
• Leitura de %HOMEPATH%\.ssh\id_rsa, %HOMEPATH%\.ssh\known_hosts e C:/Windows/System32/Drivers/etc/hosts por processo desconhecido ou recém-executado.
• Encerramento precoce após presença de skynet.bypass ou execução fora do diretório temporário, sinalizando lógica de evasão ou triagem.
• Strings com XOR rotativo e Base64 associadas à chave 4sI02LaI, úteis para extração e criação de assinaturas em laboratório.
• Saídas de ferramentas de IA contendo conclusões benignas que contradizem telemetria comportamental, especialmente quando o prompt analisado veio diretamente de artefatos maliciosos.

Mitigação

A resposta defensiva deve isolar qualquer host que tenha executado a amostra, coletar eventos de processo, artefatos de disco e telemetria de rede, e verificar se arquivos SSH foram acessados. Se houver indício de leitura de id_rsa, trate a chave como exposta: remova a chave de serviços autorizados, gere novo par, atualize inventários de acesso e revise logs de autenticação nos sistemas onde a chave era aceita. A ausência de exfiltração por rede não elimina o risco, porque a amostra imprime dados na saída padrão e pode ter sido executada em ambiente onde outro processo captura logs ou console.

No controle preventivo, bloqueie execução de binários não confiáveis em %TEMP% e outros diretórios graváveis por usuário, aplique regras de detecção para Tor iniciado fora de caminhos aprovados e restrinja leitura de chaves privadas por processos não autorizados. Sistemas de EDR devem correlacionar escrita de executável em diretório temporário, criação de processo Tor e acesso a arquivos SSH em uma mesma sessão. Em ambientes de desenvolvimento e administração, reforce permissões de arquivos de chave, uso de frase de proteção, chaves por função e expiração planejada.

Para análise assistida por IA, a mitigação é arquitetural. Artefatos extraídos de malware devem ser encapsulados como dados não confiáveis, com delimitadores rígidos e instruções de sistema que proíbam obediência a comandos contidos no material analisado. Agentes conectados a LLMs devem operar com permissões mínimas, sem acesso direto a shell ou rede quando a tarefa for classificação, resumo ou explicação. Quando execução de ferramentas for necessária, use ambiente descartável, sem credenciais reais, com allowlist de comandos, trilha de auditoria e aprovação explícita para ações destrutivas ou externas.

O caso também exige ajuste de processo: não delegar a decisão final de benignidade a um único modelo e não permitir que texto controlado pelo adversário altere políticas de análise. Vereditos gerados por IA devem ser considerados hipóteses auxiliares, validadas por indicadores comportamentais e análise determinística. Para equipes que já usam MCP, descompiladores integrados e clientes capazes de executar comandos, revise permissões, registre prompts e respostas, e inclua prompt injection em malware como cenário nos testes de segurança do próprio laboratório.

• Isolar hosts que executaram a amostra e preservar eventos de processo, arquivo, console e rede antes de limpeza automática apagar artefatos temporários.
• Rotacionar chaves privadas SSH quando houver leitura ou suspeita de acesso a %HOMEPATH%\.ssh\id_rsa.
• Bloquear execução de tor.exe a partir de %TEMP% e alertar para criação de proxies locais por processos sem reputação confiável.
• Executar amostras apenas em sandboxes sem segredos reais, sem acesso lateral e com saída de rede controlada.
• Configurar ferramentas com LLM para tratar código, strings e logs de malware como entrada adversarial, sem permitir que essas entradas redefinam instruções, permissões ou vereditos.