Worm Miasma: Ataque Supply Chain aos Pacotes npm da Red Hat

O que aconteceu?

No dia 1º de junho de 2026, a Wiz Research revelou uma campanha sofisticada de supply chain que comprometeu pelo menos 32 pacotes sob o escopo @redhat-cloud-services no registro npm. O worm, batizado de Miasma (“A Praga que se Espalha”), foi projetado para roubar credenciais de nuvem em escala — AWS, Azure, GCP, tokens do GitHub Actions, tokens do HashiCorp Vault e segredos do Kubernetes — executando scripts maliciosos silenciosamente durante o npm install.

Pior: todas as versões maliciosas foram publicadas com SLSA Build Level 3 válido — um golpe direto na confiança que a indústria deposita em proveniência de artefatos. O ataque não apenas explorou uma conta GitHub de mantenedor comprometida; ele sequestrou o pipeline legítimo da Red Hat e usou sua própria infraestrutura de build contra ela.

Mecanismo do Ataque em 10 Fases

De acordo com a análise detalhada da Microsoft Threat Intelligence, o Miasma operava em dez estágios distintos, cada um projetado para evadir defesas e maximizar a extração de credenciais:

1. Delivery & Execution: O hook preinstall no package.json executava automaticamente node index.js durante npm install, sem interação do usuário.
2. Unpacking em Estágios: Quatro camadas de ofuscação — ROT → AES-128-GCM → download do runtime Bun → payload final. Cada estágio descriptografava o seguinte.
3. Environment Gating: Validava se estava em ambiente de CI/CD antes de ativar capacidades agressivas, evitando detecção em máquinas de desenvolvedor.
4. Defense Evasion: Injeta entradas em /etc/hosts para neutralizar ferramentas de segurança e bloquear telemetria.
5. Credential Access: Varredura sistemática de mais de 15 categorias de segredos — tokens OIDC, chaves IAM, tokens de service account, kubeconfig, credenciais de CI/CD.
6. Privilege Escalation: Insere echo 'runner ALL=(ALL) NOPASSWD:ALL' > /mnt/runner para obter sudo sem senha no runner do GitHub Actions.
7. Persistence: Monitora ativamente tokens roubados e implanta payloads secundários para manter acesso contínuo.
8. Exfiltration: Três canais C2 distintos, incluindo abuso da própria infraestrutura do GitHub para exfiltrar dados.
9. Self-Propagation: Republica pacotes comprometidos com SLSA provenance forjado — comportamento de worm que infecta novas vítimas.
10. Destructive Tripwire: Se um token honeypot fosse acionado, executava rm -rf ~/ para destruir evidências.

Técnica Crítica: Leitura de Memória do Runner

Uma das técnicas mais inovadoras do Miasma era a capacidade de ler segredos diretamente da memória do processo Runner.Worker no GitHub Actions, contornando o masking de segredos:

# Extrai segredos da memória do runner, bypassando o masking do GitHub Actions
tr -d '\0' | grep -aoE '"[^"]+":{"value":"[^"]*","isSecret":true}' | sort -u

Isso permitia ao atacante roubar o token OIDC do runner — o mesmo usado para trocar por permissões de publish no npm — e republicar pacotes como se fossem versões legítimas.

SLSA Provenance: A Ferramenta Virou Arma

Este é o ponto mais preocupante do ataque Miasma. O SLSA (Supply-chain Levels for Software Artifacts) é um framework de confiança que classifica a segurança de artefatos de software em níveis de 1 a 4. Todas as versões maliciosas do Miasma foram publicadas com SLSA Build Level 3 válido, assinado via Sigstore.

O certificado SLSA atestava corretamente que os pacotes foram construídos pelo pipeline legítimo da Red Hat. O problema? O pipeline estava sequestrado.

Isso quebra a premissa fundamental da proveniência: SLSA não verifica quem acionou o pipeline, apenas que o pipeline o construiu. Se um atacante controla a conta que aciona o build, o SLSA atesta a construção, não a intenção.

Raízes do Ataque: Conta GitHub Comprometida + Commits Órfãos

A entrada do atacante foi uma conta GitHub de um funcionário da Red Hat comprometida. Em apenas alguns minutos (10:53 UTC), o atacante fez push de commits órfãos maliciosos diretamente em três repositórios da organização RedHatInsights:

• RedHatInsights/frontend-components (branch oidc-61fff775)
• RedHatInsights/javascript-clients (branch oidc-4d5900f3)
• RedHatInsights/platform-frontend-ai-toolkit (branch oidc-2530ec68)

Cada commit órfão continha um workflow GitHub Actions malicioso (ci.yaml) solicitando id-token: write — a permissão necessária para trocar o token OIDC por tokens de publish no npm — e um script ofuscado _index.js de 4,2 MB (pacotes legítimos normalmente têm ~200 KB).

Por serem commits órfãos (sem parentesco com a branch principal), eles bypassaram code review e branch protections — não havia PR para revisar.

Conexão com TeamPCP: De Shai-Hulud a Miasma

O Miasma não surgiu do nada. Ele é uma evolução direta do Mini Shai-Hulud, um worm de código aberto publicado pelo grupo TeamPCP (UNC6780) em 12 de maio de 2026. A linhagem completa:

Geração	Nome	1ª Aparição	Destaque
1ª	Shai-Hulud	Set/2025	Primeiro worm auto-replicante em npm, 500+ pacotes
2ª	SHA1-Hulud	Nov/2025	Variante com Bun runtime, ofuscação melhorada
3ª	SANDWORM_MODE	Mar/2026	Técnicas evasivas avançadas
4ª	Mini Shai-Hulud	Abr/2026	SLSA forjado, OIDC hijack, hooks em IDEs e agentes de IA

Quando o TeamPCP tornou o código do Mini Shai-Hulud público (no GitHub e BreachForums), o worm se tornou commodity — qualquer ator com recursos mínimos poderia adaptá-lo. O Miasma é a prova de que isso aconteceu.

O impacto total do ecossistema TeamPCP até hoje: 170+ pacotes comprometidos entre npm e PyPI, 518 milhões+ de downloads semanais cumulativos, 400+ repositórios de credenciais criados, organizações como OpenAI, Mistral AI, GitHub (~3.800 repositórios internos) e a Comissão Europeia afetadas.

Indicadores de Comprometimento (IOCs)

Para equipes de blue team e CSIRT, os principais indicadores do Miasma incluem:

• Tamanho anormal: Arquivos index.js com 4,2 MB (pacotes legítimos têm ~200 KB)
• Descrição suspeita: Repositórios com descrição “Miasma: The Spreading Blight”
• User-Agent: google-api-nodejs-client/7.0.0 gl-node/20.11.0 gccl/7.0.0
• Cadeia de processos: node → shell → bun → payload — altamente incomum em instalações npm típicas
• Hooks suspeitos: SessionStart em ~/.claude/settings.json e folderOpen em .vscode/tasks.json
• Pacotes com hasInstallScript: true que nunca antes tinham lifecycle hooks

Outras Ameaças da Semana (25/05 a 07/06/2026)

O Miasma não agiu sozinho. A mesma semana trouxe alertas importantes que todo time de segurança precisa conhecer:

CVE-2026-0257: PAN-OS GlobalProtect Authentication Bypass

Adicionado ao KEV em 29 de maio com prazo de remediação para 1º de junho. A falha permite que um atacante não autenticado estabeleça uma conexão VPN através do gateway GlobalProtect quando cookies de autenticação estão habilitados com uma configuração específica de certificado. IPs de ataque confirmados pela Unit 42:

23.128.228[.]6, 104.207.144[.]154, 146.19.216[.]119,
146.19.216[.]120, 179.43.172[.]213, 185.195.232[.]139,
198.12.106[.]60, 202.144.192[.]47

Ironicamente, a infraestrutura de rede da PAN — o gateway de acesso remoto — foi transformada em um vetor de ataque não autenticado.

CVE-2022-0492: Container Escape em cgroups v1 — 3 Anos Depois

Adicionado ao KEV em 2 de junho com prazo de 5 de junho — apenas 3 dias para remediação. Esta vulnerabilidade de 2022 no subsistema cgroups v1 do kernel Linux permite que um processo dentro de um container escape para o host com privilégios root, modificando o arquivo release_agent.

Por que isso importa agora? Porque alguém encontrou exploração ativa em junho de 2026 — três anos após a divulgação inicial. O sinal operacional é a recência da exploração, não a recência da descoberta. Infraestruturas cloud-native com cgroups v1 ativos — especialmente clusters Kubernetes que não migraram para cgroups v2 — estão expostas.

Sophos: Laboratório de Evasão de EDR com Coordenação de Agentes de IA

A Sophos documentou um repositório Git de um ator de ameaças contendo um painel automatizado de descoberta de Active Directory e um laboratório que iterativamente desenvolve e testa malware contra três EDRs comerciais (Sophos, CrowdStrike e Microsoft Defender). O framework usava múltiplos agentes de IA coordenados por um agente Claude Opus 4.5, conectados via Model Context Protocol (MCP) a repositórios Git e construídos com ferramentas como Cursor e Ludus.

Executive Order: IA e Segurança Cibernética

Em 2 de junho, a Casa Branca emitiu a ordem executiva “Promoting Advanced Artificial Intelligence Innovation and Security”, estabelecendo um framework voluntário de avaliação de fronteira para modelos de IA e um processo de benchmarking classificado (liderado pela NSA) para capacidades cibernéticas ofensivas. O elemento mais relevante para times de segurança: o AI Cybersecurity Clearinghouse, um mecanismo voluntário de coordenação indústria-governo para identificação e remediação de vulnerabilidades.

Lições para Times de CSIRT e Security Engineering

A história do Miasma consolida lições que todo time de segurança deveria internalizar:

1. Pinning de versão + lockfile enforcement: Use npm ci em CI/CD, nunca npm install.
2. Min-release-age: npm v11.10+ suporta min-release-age=7d no .npmrc — bloqueia pacotes publicados há menos de 7 dias.
3. Auditoria de lifecycle hooks: Automatize flag em PRs que adicionam dependências com hasInstallScript: true e sem histórico anterior de hooks.
4. Rotação imediata de credenciais: Após qualquer instalação suspeita em CI/CD, rotacione todos os segredos — tokens OIDC, chaves de nuvem, tokens de serviço.
5. Não confie em SLSA como única camada: SLSA atesta a construção, não a intenção. Vincule OIDC a workflow+branch específicos, não ao repositório inteiro.
6. Monitoramento de processos anormais: Detecte a assinatura node → shell → bun → payload em runners de CI/CD.
7. Segmentação de rede para runners: Bloqueie egress desnecessário de ambientes de build.

O Padrão Recorrente: Velocidade como Vetor

O que unifica todas as histórias desta semana — Miasma, PAN-OS no KEV, cgroups ressuscitado, Sophos AI-lab, Cisco redesenho de disclosure — é um padrão inescapável: a ofensiva está se movendo mais rápido que os controles construídos para contê-la.

Como disse Nick Reva (DoorDash) no episódio do Cloud Security Podcast desta semana: “O controle que sobrevive é aquele que já está rodando onde o trabalho acontece — no pull request, no pipeline, contra telemetria de runtime em tempo real — com um humano reservado apenas para a decisão consequencial. Guardrails, não gates.”

Para o CSIRT brasileiro, a mensagem é clara: supply chain não é mais um problema de “se” — é de “quando”. A pergunta não é se seu ecossistema de dependências será atacado, mas se você conseguirá detectar a tempo.

Fontes e Referências

• Wiz Research — Miasma: Supply-Chain Attack Targeting Red Hat npm Packages
• Microsoft Security Blog — Preinstall Persistence Inside Red Hat npm: Miasma Campaign
• Palo Alto Unit 42 — CVE-2026-0257 Threat Brief
• CISA KEV Catalog
• Tenable — Mini Shai-Hulud FAQ
• Cloud Security Newsletter — Security at the Speed of Engineering
• Sonatype 2026 State of the Software Supply Chain Report
• ArmorCode — Defending Against npm Supply Chain Attacks

---

Pesquisa e análise: N00TROP1C — NULLTROPIC, 2026. Fontes: Cloud Security Newsletter, Wiz Research, Microsoft Threat Intelligence, Palo Alto Unit 42, BleepingComputer, CISA, The Hacker News.