Por que o comprometimento do gateway LiteLLM AI é tão perigoso?

Uma proporção significativa dos incidentes cibernéticos está ligada a ataques à cadeia de abastecimento e esta proporção está em constante crescimento. Ao longo do ano passado, vimos uma grande variedade de métodos utilizados em tais ataques, desde a criação de bibliotecas de código aberto maliciosas, mas aparentemente legítimas, ou ataques retardados a tais bibliotecas aparentemente legítimas, até ao método mais simples mas eficaz – comprometer as contas de proprietários de bibliotecas populares para posteriormente libertarem versões maliciosas das suas bibliotecas. Essas bibliotecas são usadas por desenvolvedores em todos os lugares e estão incluídas em muitas soluções e serviços. As consequências de um ataque podem variar amplamente, desde a entrega de malware ao dispositivo de um desenvolvedor até o comprometimento de uma infraestrutura inteira, caso a biblioteca maliciosa tenha penetrado no código de um serviço ou produto.

Foi exatamente isso que aconteceu em março de 2026, quando invasores injetaram código malicioso na popular biblioteca Python LiteLLM, que serve como um gateway multifuncional para um grande conjunto de agentes de IA. Os invasores lançaram duas versões trojanizadas do LiteLLM que entregavam scripts maliciosos ao sistema da vítima. Ambas as versões chegaram ao repositório PyPI para Python. Uma análise técnica revelou que os principais alvos dos invasores eram servidores que armazenavam dados confidenciais relacionados a AWS, Kubernetes, NPM, etc., bem como vários bancos de dados (MySQL, PostgreSQL, MongoDB, etc.). Neste último caso, os invasores estavam interessados ​​principalmente nas configurações do banco de dados. Além disso, a lógica do malware incluía funcionalidade para roubar dados confidenciais de carteiras criptografadas e técnicas para estabelecer uma posição no cluster Kubernetes.

Comprometimento do repositório

O comprometimento afetou o canal de distribuição de pacotes via PyPI: em 24 de março de 2026, versões maliciosas do LiteLLM litellm==1.82.7 e litellm==1.82.8 foram carregadas no registro. Foi especificamente o conteúdo da distribuição do pacote que foi comprometido: na versão 1.82.7, o código malicioso foi incorporado em proxy_server.py, e na 1.82.8, o arquivo litellm_init.pth foi adicionado.

Análise técnica

Ambas as versões da biblioteca continham o mesmo código malicioso, mas sua execução foi implementada de forma diferente. Na versão 1.82.7, ele era executado apenas quando a funcionalidade do proxy era importada, enquanto na 1.82.8 foi adicionado um arquivo .pth que era capaz de executar o código toda vez que o interpretador iniciasse.

O código malicioso nos arquivos proxy_server.py e litellm_init.pth continha código Python codificado em Base64. Após a execução, o script infectado salvou esse código como um arquivo p.py e o executou imediatamente.

O script p.py lançou a carga principal – outro script, também codificado em Base64 – sem salvá-lo em disco. Ao mesmo tempo, ele gravou a saída dessa carga em um arquivo no diretório a partir do qual foi iniciada. Antes de ser escrita, a saída foi criptografada usando o algoritmo AES-256-CBC com uma chave aleatória gerada no código, que foi salva no arquivo session.key. O arquivo de chave também foi criptografado – usando uma chave RSA pública pré-inicializada.

A chave criptografada e a saída foram combinadas em um arquivo tpcp.tar.gz e enviadas ao servidor remoto dos invasores.

O que exatamente aconteceu na carga maliciosa, cuja saída foi enviada ao servidor C2? Depois de iniciado, uma verificação recursiva dos diretórios de trabalho no sistema da vítima (/root, /app/, /var/www, etc.) começou. Em cada diretório, o script verificou o conteúdo dos arquivos, que foi enviado para o buffer stdout, de onde foi salvo no arquivo mencionado como resultado. Em seguida, o script coletou informações do sistema e também as salvou em um arquivo. Depois disso, procedeu à busca de dados confidenciais. Estava interessado nos seguintes dados localizados em servidores e nas infraestruturas de diversos serviços:

• Chaves SSH
• Contas GIT
• Arquivos .env
• Configurações de AWS, Kubernetes, serviço de e-mail, banco de dados e WireGuard
• arquivos relacionados ao Helm, Terraform e CI
• Chaves e certificados TLS

Uma característica notável deste malware é que ele não se limita a roubar arquivos e configurações do disco, mas também tenta extrair segredos de tempo de execução da infraestrutura em nuvem.

O código acima utiliza os endereços 169.254.169.254 e 169.254.170.2. O primeiro corresponde ao AWS Instance Metadata Service (IMDS), por meio do qual uma instância EC2 (um servidor virtual na AWS, uma máquina rodando na nuvem) pode recuperar metadados e credenciais temporárias de função IAM (uma conta AWS com um conjunto de permissões que um serviço ou aplicativo pode usar para obter credenciais temporárias para chamadas à API AWS). A segunda é usada no Amazon ECS para emitir credenciais temporárias para um contêiner durante a execução. Assim, o script malicioso tem como alvo não apenas segredos estáticos, mas também aqueles emitidos pela nuvem que podem conceder acesso direto aos recursos da AWS no momento da infecção.

Além disso, o script procura configurações de carteira criptográfica, bem como webhooks associados aos mensageiros Slack e Discord. Estes últimos indicam que os invasores estão interessados ​​não apenas nos segredos e contas da infraestrutura, mas também nos canais de comunicação dentro da equipe de desenvolvimento.

No próximo estágio, o malware passa da coleta de dados para o estabelecimento de uma base na infraestrutura de cluster do Kubernetes: se tiver acesso suficiente, ele configura um pod privilegiado (a menor unidade de execução no Kubernetes, contendo um ou mais contêineres), habilitando a opção securityContext.privileged=true e monta o sistema de arquivos raiz do nó via hostPath. Isso permite que ele escape do contêiner e execute ações no nível do nó.

Em seguida, o malware executa outro estágio de infecção – ele salva um script codificado em base64 disfarçado como um componente legítimo do sistema no disco do nó Kubernetes no caminho /root/.config/sysmon/sysmon.py e o registra via systemd. Após o lançamento, o script aguarda um atraso inicial de 300 segundos e, em seguida, começa a entrar em contato periodicamente com o nó C2 checkmarx(.)zone/raw, recuperando um link para a próxima carga a partir daí. Se o valor recebido for diferente do estado salvo anteriormente em /tmp/.pg_state, o script baixa um novo arquivo em /tmp/pglog, torna-o executável e o executa em segundo plano. Nesse estágio, os invasores ganham uma posição segura no sistema e são capazes de entregar regularmente cargas atualizadas sem a necessidade de reinjeção. Como a carga maliciosa não é gravada no diretório de arquivos temporários do contêiner, mas diretamente no nó do cluster Kubernetes, os invasores manterão o acesso à infraestrutura mesmo após o encerramento do contêiner.

Um cenário semelhante é usado para persistência local: na ausência do Kubernetes, o script sysmon.py é implantado no diretório do usuário em ~/.config/sysmon/sysmon.py e também é registrado como um serviço via systemd.

Versão OpenVSX do malware

Ao analisar arquivos que se comunicam com o servidor C2, descobrimos versões maliciosas de duas extensões de software comuns da Checkmarx: ast-results 2.53.0 e cx-dev-assist 1.7.0. Checkmarx é usado para avaliação de segurança de aplicativos. Essas extensões trojanizadas continham código malicioso que entregava a versão NodeJS do malware descrito acima.

Esta versão é baixada de checkmarx(.)zone/static/checkmarx-util-1.0.4.tgz usando utilitários de instalação de pacote NodeJS e é chamada checkmarx-util. Sua principal diferença em relação à versão Python é que ela não tenta elevar privilégios ao nível do nó do Kubernetes e não cria um pod privilegiado para persistência. Em vez disso, implementa persistência local no ambiente atual. Isso significa que a variante NodeJS persiste apenas onde já está em execução.

Além disso, a lista de pastas para procurar e roubar segredos é significativamente menor nesta versão do que na variante Python.

As extensões Checkmarx são usadas para verificar configurações de código e infraestrutura, portanto, seu comprometimento é bastante perigoso: um invasor obtém acesso não apenas aos arquivos do projeto, mas também a uma parte significativa do ambiente de desenvolvimento, tokens e configurações locais.

Vitimologia

Ao avaliar o impacto do ataque, vimos vítimas em todo o mundo. A maioria das tentativas de infecção ocorreu na Rússia, China, Brasil, Holanda e Emirados Árabes Unidos.

Conclusão

Como mostra a análise técnica, os scripts maliciosos encontrados nas versões LiteLLM são perigosos não apenas porque roubam arquivos contendo dados confidenciais, mas também porque visam vários componentes críticos da infraestrutura simultaneamente: o sistema local, os segredos do tempo de execução da nuvem, o cluster Kubernetes e até mesmo chaves criptográficas. Um escopo tão amplo de coleta de dados permite que um invasor passe rapidamente do comprometimento de um único sistema e ambiente Python para a apreensão de contas de serviço, segredos e infraestruturas inteiras.

Prevenção e proteção

Para se proteger contra infecções deste tipo, recomendamos a utilização de uma solução especializada para monitorizar componentes de código aberto. A Kaspersky fornece dados em tempo real são alimentados em pacotes e bibliotecas comprometidosque pode ser utilizado para proteger a cadeia de abastecimento e proteger os projetos de desenvolvimento contra tais ameaças.

Soluções de segurança residencial, como Kaspersky Premium, ajudam a garantir a segurança dos dispositivos pessoais, fornecendo proteção em várias camadas que previne e neutraliza ameaças de infecção. Além disso, nossa solução pode restaurar a funcionalidade de um dispositivo no caso de uma infecção por malware.

Para proteger dispositivos corporativos, recomendamos o uso de uma solução complexa como Kaspersky PRÓXIMOque permite construir um sistema de segurança flexível e eficaz. Os produtos desta linha fornecem visibilidade de ameaças e proteção em tempo real, bem como recursos EDR e XDR para investigação e resposta a ameaças.

No momento em que este artigo foi escrito, as versões comprometidas do LiteLLM já foram removidas do PyPI e do OpenVSX. Se você os utilizou, e como resposta proativa à ameaça, recomendamos tomar as seguintes medidas em seus sistemas e infraestrutura:

• Execute uma verificação completa do sistema usando uma solução de segurança confiável.
• Alterne todas as credenciais potencialmente comprometidas – chaves de API, variáveis ​​de ambiente, chaves SSH, tokens de conta de serviço do Kubernetes e outros segredos.
• Verifique hosts e clusters em busca de sinais de comprometimento – a presença de arquivos ~/.config/sysmon/sysmon.py, pods suspeitos no Kubernetes.
• Limpe o cache e faça um inventário dos módulos PyPI: verifique se há módulos maliciosos e reverta para versões limpas.
• Verifique se há indicadores de comprometimento (arquivos no sistema ou sinais de rede).

Indicadores de compromisso:

URLs
modelos(.)litellm(.)nuvem
checkmarx(.)zona

Pacotes infectados
85ED77A21B88CAE721F369FA6B7BBBA3
2E3A4412A7A487B32C5715167C755D08
0FCCC8E3A03896F45726203074AE225D

Roteiros
F5560871F6002982A6A2CC0B3EE739F7
CDE4951BEE7E28AC8A29D33D34A41AE5
05BACBE163EF0393C2416CBD05E45E74