Aviso de segurança: pacotes npm de @asyncapi comprometidos disparam o framework malicioso Miasma durante builds e fluxos de CI

Pesquisadores de segurança identificaram uma campanha de compromisso da cadeia de abastecimento que afetou vários pacotes npm do espaço de nomes @asyncapi, e que distribuíam um carregador em várias etapas que desemboca em um framework malicioso avançado conhecido como "Miasma". Os pacotes afetados incluíam versões concretas. @asyncapi/generator- helpers, @asyncapi/generator- components, @asyncapi/generator e @asyncapi/specs; esses pacotes continham um ficheiro injetado que, ao ser carregado por Node.js com require (), executava um primeiro payload ofuscado que descarregava a partir do IPFS um segundo estádio encriptado chamado "sync.js". O recurso de descarga observado foi publicado na passarela pública: ipfs.io/ipfs/QmQobZSp1wRPrpSEQ56qnyq7ecZh5Bg5k1fnjt4SUwwHb9.

A cadeia de infecção descrita não depende de hooks de instalação (preinstall/postinstall) mas da carga em tempo de execução: o código malicioso é ativado quando a livraria infectada é require ()d durante um build ou fluxo de trabalho da CI. Essa diferença é crucial para a detecção e resposta, porque um simples npm install que não chegue a carregar a livraria pode não ativar a execução, enquanto uma compilação ou um job de CI que importe o módulo sim o fará.

O loader "sync.js" abriga dois componentes: um é o payload JavaScript final cifrado que contém o framework Miasma e outro é uma grande estrutura cifrada usada pelo runtime para executar cadeias de processos. O framework relatado empacote centenas de módulos e suporta múltiplos canais de comando e controle, incluindo HTTP REST, relés Nostr, IPFS, BitTorrent DHT, libp2p GossipSub e até um contrato inteligente no Ethereum. Entre suas capacidades encontram-se roubo de credenciais, envenenamento de ferramentas de IA, movimento lateral por LAN e propagação tipo minhoca a registries como npm, PyPI e Cargo, além de mecanismos de persistência em systemd, crontab, launchd e chaves do registro do Windows.

As análises também mostram funcionalidades operacionais maduras: criptografia de comunicações e tarefas, transporte de subida de arquivos, assinatura de nós e atualização remota de payloads. O malware inclui um mecanismo de "dead man's switch" que vigia um token roubado e pode ativar uma remoção de pastas se o token for revogado, e evita sistemas que pareçam sandboxes, máquinas virtuais, equipamentos configurados em russo ou aqueles com software de segurança concreto instalado (por exemplo, CrowdStrike, SentinelOne, Microsoft Defender e outros), o que indica intenção de permanecer operacional em ambientes reais e evitar análises.

Um ponto operacional importante que diferenciam esta intrusão é o vetor de publicação: segundo as equipes envolvidas na pesquisa, o atacante obteve acesso para fazer push aos repositórios e usou os fluxos legítimos do GitHub Actions do projeto, publicando pacotes através da integração OIDC do GitHub para npm. Isso produziu pacotes com attestations de SLSA e OIDC válidos, o que demonstra que as builds foram realizadas por uma workflow autorizada, mas não garante que os commits que a ativaram fossem legítimos. Em outras palavras, a presença de testes de procedência SLSA não substitui o controle estrito sobre quem pode push e o que commits são aceitos.

As versões maliciosas já foram retiradas do registro npm, mas o dano pode ter sido materializado em qualquer endpoint que tenha importado e executado esses módulos em builds, ambientes de desenvolvimento ou jobs de CI. Deve ser tratado como potencialmente comprometido qualquer sistema que carregou as versões afectadas, e não assumir segurança por ausência de scripts de instalação em package.json.

Para equipes e responsáveis, as ações imediatas recomendadas são isolar e preservar artefatos se suspeitam de execução, auditar dependências e builds, e procurar indicadores concretos: rastrear nos lockfiles e na árvore de dependências versões afetadas de @asyncapi; procurar em repositórios e na base de código chamadas a require () sobre esses pacotes; detectar processos Node.js filhos que se executem em segundo plano e arquivos chamados "sync.js" escritos em rotas específicas do sistema; verificar a presença de unidades systemd, entradas de crontab, launchd e chaves Run no Registro do Windows criadas recentemente. Também convém bloquear a nível de rede o CID/IPFS conhecido e a passarela envolvida para impedir futuras descargas: além do link IPFS anterior, as organizações podem aplicar controles de egress para gateways públicos.

A nível de prevenção da cadeia de abastecimento, é fundamental restringir quem pode modificar repositórios e o que workflows podem publicar artefatos. Rever proteções de ramos, forçar revisões humanas antes de merges que disparem releases, auditar os secrets e credenciais de push ao repositório, e limitar as identidades do GitHub Actions com permissões mínimas. Ter em conta que as attestations de OIDC/SLSA confirmam que a build foi produzida pela workflow confiante, mas não substituem controlos de integridade do repositório nem a proteção das credenciais de push. Documentação útil sobre o modelo OIDC no GitHub e sobre a iniciativa SLSA está disponível nos recursos oficiais: GitHub - OIDC para GitHub Actions e SLSA (Supply-chain Levels for Software Artifacts).

Na fase de resposta e remediação, convém combinar medidas técnicas e de processo: revogar e rotar credenciais expostas, revisar e substituir pacotes comprometidos por versões limpas ou reconstruídas desde fontes verificadas, reconstruir artefatos de releases em ambientes controlados e verificar hashes, e executar análises forenses em endpoints suspeitos com EDR/antimalware para detectar exfiltrações, persistências e módulos carregados por Node.js. Para reduzir o risco futuro, implantar digitalização contínua de dependências, assinar releases e políticas que limitem a publicação automática sem revisão do código que dispara a workflow.

Este incidente sublinha que a confiança na cadeia de abastecimento é condicionada: as garantias de workflow e de assinatura facilitam a rastreabilidade, mas não substituem a necessidade de controlos de acesso, revisão humana e monitorização de comportamento. Se a sua organização usou alguma das versões comprometidas, age como se houvesse compromisso: aisla, investiga e recupera de fontes limpas, e aproveita a lição para endurecer controles em repositórios e CI/CD.