Linha do Tempo de uma Campanha em Escala

No dia 1 de junho de 2026, pesquisadores de segurança identificaram um comprometimento massivo na cadeia de suprimentos de software que afetou mais de 30 pacotes npm oficiais da Red Hat. Batizada de “Miasma”, a operação utilizou uma conta GitHub comprometida de um funcionário da Red Hat para injetar código malicioso em pacotes do ecossistema @redhat-cloud-services, acumulando mais de 116 mil downloads semanais. Este incidente não é isolado — ele representa o capítulo mais recente de uma campanha orquestrada que já atingiu Bitwarden, SAP, PyTorch Lightning, Mistral, TanStack e Microsoft desde abril de 2026.

O Que é o Miasma?

Miasma é uma variante do malware Mini Shai-Hulud, originalmente desenvolvido e open-sourced pelo grupo TeamPCP em maio de 2026. O nome “Miasma” (do grego, “miasma” — mancha ou contaminação) foi uma escolha temática do atacante, que trocou as referências originais de Dune por mitologia grega. Os repositórios criados pelos atacantes traziam a descrição “Miasma: The Spreading Blight”.

“Se você instalou qualquer versão comprometida desde 1º de junho de 2026, considere todos os segredos de CI, credenciais de nuvem, chaves SSH e tokens npm como comprometidos — e rotacione-os imediatamente.” — Aikido Security

Mecanismo do Ataque: Trusted Publishing Bypass

A técnica utilizada revela uma sofisticação preocupante. O atacante, tendo comprometido a conta GitHub de um funcionário da Red Hat, realizou os seguintes passos:

  1. Push de orphan commits — commits órfãos que substituíam o histórico do repositório, pulando completamente o processo de code review.
  2. Workflow malicioso — cada commit continha um arquivo ci.yaml que solicitava permissão id-token: write do GitHub Actions.
  3. OIDC para npm — o workflow solicitava um token OIDC de curta duração do GitHub e o usava para autenticar diretamente no endpoint de trusted publishing do npm.
  4. Publicação com provenance — as versões comprometidas eram publicadas com assinaturas SLSA válidas, o que torna a detecção por ferramentas de verificação de integridade muito mais difícil.
# Estrutura do workflow malicioso
name: release
on:
  push:
    branches: ['*']
jobs:
  release:
    runs-on: ubuntu-latest
    permissions:
      id-token: write      # Solicita token OIDC
      contents: read
    steps:
      - uses: actions/checkout@v4
      - uses: oven-sh/setup-bun@v1
      - name: prepare
        run: bun run _index.js
        env:
          OIDC_PACKAGES: "pkg1, pkg2, ..."

O script _index.js era um payload JavaScript de 4.2 MB altamente ofuscado, utilizando eval() e decodificação ROT. Cada infecção recebia um payload criptografado único, tornando IOCs baseados em hash pouco úteis.

O Que o Malware Rouba?

A execução ocorria automaticamente via script preinstall no package.json, antes mesmo de qualquer código legítimo ser executado. O malware realizava uma varredura completa do sistema:

  • CI/CD: GitHub Actions secrets (GITHUB_TOKEN, ACTIONS_RUNTIME_TOKEN)
  • AWS: Access keys, session tokens, credenciais IMDS
  • GCP: Application Default Credentials, service account keys
  • Azure: Service principal credentials, managed identity tokens
  • Infraestrutura: Tokens HashiCorp Vault, kubeconfig, tokens Kubernetes
  • Pacotes: Tokens de publicação npm e PyPI
  • Criptografia: Chaves SSH privadas, chaves GPG
  • Config: Arquivos .env em todo o filesystem

Uma novidade nesta variante foi a adição de coletores de identidade na nuvem — o malware agora também enumera e exfiltra todas as identidades (GCP e Azure) acessíveis pela máquina infectada, não apenas credenciais estáticas.

Cronologia da Campanha Mini Shai-Hulud

O ataque Miasma não acontece no vácuo. Ele faz parte de uma campanha de supply chain que já dura mais de um mês:

DataAlvoVetor
22 Abr 2026@bitwarden/cliGitHub Actions workflow envenenado
29 Abr 2026Pacotes SAP npmToken npm vazado em PR malicioso
30 Abr 2026PyTorch Lightning (PyPI)Comprometimento direto
12 Mai 2026Mistral, TanStack (160+ pacotes)OIDC trusted publishing bypass
12 Mai 2026TeamPCP publica código-fonteOpen-source do Shai-Hulud
19 Mai 2026Microsoft DurableTask npmConta GitHub previamente comprometida
1 Jun 2026Red Hat (Miasma)Conta funcionario + OIDC bypass

Pacotes Afetados (Principais)

Foram identificadas 96 versões comprometidas em 32 pacotes. Entre os mais críticos:

  • @redhat-cloud-services/chrome (2.3.1, 2.3.2)
  • @redhat-cloud-services/frontend-components (7.7.2, 7.7.3, 7.7.5)
  • @redhat-cloud-services/compliance-client (4.0.3, 4.0.4, 4.0.6)
  • @redhat-cloud-services/topological-inventory-client (3.0.10, 3.0.11, 3.0.13)
  • @redhat-cloud-services/rbac-client (9.0.3, 9.0.4, 9.0.6)
  • @redhat-cloud-services/host-inventory-client (5.0.3, 5.0.4, 5.0.6)

Attribution: TeamPCP ou Copycat?

As TTPs (Táticas, Técnicas e Procedimentos) observadas no Miasma são consistentes com o modus operandi do TeamPCP — especialmente o uso de orphan commits, OIDC trusted publishing e a estrutura dos workflows. No entanto, como o TeamPCP tornou público o código-fonte do Mini Shai-Hulud em meados de maio, não é possível atribuir definitivamente este ataque ao grupo original. Pode ser um copycat utilizando as mesmas ferramentas.

Mitigacoes e Recomendacoes

Se sua equipe utiliza pacotes @redhat-cloud-services ou qualquer dependência do ecossistema Red Hat Hybrid Cloud Console, as seguintes ações são urgentes:

  1. Auditar versões — verifique se alguma das versões comprometidas está presente em seus lockfiles (package-lock.json, yarn.lock, pnpm-lock.yaml).
  2. Rotacionar credenciais — assuma comprometimento total de secrets de CI/CD, credenciais cloud, chaves SSH e tokens npm/PyPI.
  3. Revisar atividade GitHub — busque commits suspeitos, tokens recém-criados e execuções de workflow não autorizadas.
  4. Implementar allowlisting — mantenha listas de dependências aprovadas e utilize ferramentas como Aikido Safe Chain para verificar pacotes antes da instalação.
  5. Monitorar proveniência SLSA — implemente verificação de assinaturas SLSA em pipelines de CI/CD.
  6. Restringir trusted publishing — configure limites rigorosos no npm para quais repositórios e ambientes podem publicar usando OIDC.
  7. SBOM e análise de dependências — gere SBOMs regularmente (CycloneDX/SPDX) e cruze com feeds de inteligência de ameaças.

Contexto Adicional da Semana

Além do Miasma, outras notícias de segurança marcaram os primeiros dias de junho:

  • CVE-2026-41089 (CVSS 9.8) — Vulnerabilidade crítica de RCE no Windows Netlogon está sendo explorada ativamente. Atacantes sem autenticação podem executar código remotamente em domain controllers. O patch foi lançado no Patch Tuesday de maio, mas a exploração em massa começou na última semana. O Centro de Cibersegurança da Belgica (CCB) emitiu alerta urgente.
  • Instagram + Meta AI — Hackers estão sequestrando contas de alto perfil (incluindo a conta do Obama White House) ao explorar o assistente de suporte baseado em IA da Meta. O ataque requer apenas uma VPN com IP próximo à localização da vitima e uma solicitação para o chatbot alterar o email da conta.
  • 1 em cada 10 novos dominios — O relatório da Interisle revelou que 8,5 milhões dos 84,9 milhões de dominios registrados em 2025 foram adicionados a blocklists de segurança. Cinco registradoras respondem por metade desses dominios maliciosos.
  • Rust bane codigo gerado por IA — A linguagem Rust proibiu contribuições de código gerado por IA, seguindo o movimento do Zig e de algumas distribuições Linux.
  • MITRE doa Caldera para Apache — A plataforma de emulação de adversarios foi transferida para a Apache Software Foundation, tornando-se Apache Caldera.

Conclusao

O ataque Miasma à Red Hat via npm representa um divisor de aguas na segurança da cadeia de suprimentos de software. A combinação de contas GitHub comprometidas com trusted publishing OIDC permite que atacantes publiquem código malicioso com assinaturas SLSA válidas, tornando a detecção extremamente desafiadora para equipes de segurança tradicionais.

Para equipes CSIRT e DevSecOps, a mensagem é clara: a cadeia de suprimentos de software não é mais apenas um risco teorico — é um vetor de ataque ativo e em escala industrial. Ferramentas de monitoramento de dependencias, SBOMs atualizados e políticas rigorosas de trusted publishing deixaram de ser “boas praticas” para se tornarem requisitos minimos de segurança operacional.

Pesquisa e analise: N00TROP1C — NULLTROPIC, 2026. Fontes: Aikido Security, Wiz Research, Snyk, Red Hat Security (RHSB-2026-006), Risky.Biz, BleepingComputer, KrebsOnSecurity, Interisle.


Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *