Quatro pacotes comprometidos no namespace @asyncapi do npm foram observados distribuindo um botnet loader em múltiplas etapas, segundo descobertas da OX Security, SafeDep, Socket e StepSecurity.
Os pacotes afetados são os seguintes:
@asyncapi/[email protected]
@asyncapi/[email protected]
@asyncapi/[email protected]
@asyncapi/specs (v6.11.2 e v6.11.2-alpha.1)
“Os pacotes comprometidos implantam um payload ofuscado de primeira etapa que baixa um payload criptografado de segunda etapa, identificado como Miasma, a partir do IPFS”, afirmou a Socket.
Os pacotes adulterados trazem um implante oculto em JavaScript, e cada um deles contém um arquivo-fonte injetado que se decodifica no mesmo downloader de segunda etapa.
Diferentemente de versões anteriores, que usavam ganchos de instalação para disparar a execução de um payload em JavaScript, neste caso o código malicioso é executado quando o módulo infectado é carregado pelo Node.js.
Em seguida, ele inicia um processo em segundo plano desvinculado da sessão principal, que baixa e executa o malware a partir do IPFS.
O payload seguinte é um loader criptografado em JavaScript chamado “sync.js”, gravado em caminhos específicos do sistema operacional e depois executado.
A URL do downloader é “ipfs[.]io/ipfs/QmQobZSp1wRPrpSEQ56qnyq7ecZh5Bg5k1fnjt4SUwwHb9”.
O loader contém dois componentes:
o payload final criptografado em JavaScript, que se decodifica para o framework de tarefas Miasma
um grande bloco criptografado usado pelo framework de cadeia de execução do tempo de execução
O framework reúne 744 módulos e foi construído como um framework de comando que suporta seis canais independentes de comunicação C2, usando HTTP, Nostr relay, IPFS, BitTorrent DHT, malha P2P GossipSub do libp2p e um contrato inteligente da Ethereum.
Além de facilitar o roubo de credenciais, o envenenamento de ferramentas de IA, o movimento lateral na LAN e a propagação em estilo worm em registries como npm, PyPI e Cargo, o Miasma traz seu próprio mecanismo de persistência, configurando inicialização automática via systemd, crontab, launchd do macOS e chaves de autostart no Registro do Windows.
“Embora o malware apresente algumas semelhanças com as campanhas Shai-Hulud e Miasma, e contenha a string Miasma várias vezes em seu código, ele não é o mesmo que essas campanhas nem é atribuído às campanhas Miasma, Shai-Hulud ou TeamPCP que vimos no passado”, disse Moshe Siman Tov Bustan, da OX Security.
Além disso, ele incorpora um mecanismo de destruição condicional que monitora um token roubado e aciona a limpeza de um diretório se o token for revogado.
Também evita sistemas identificados como sandbox ou ambientes virtuais, assim como aqueles com o idioma atual definido como russo ou com ferramentas de segurança da CrowdStrike, SentinelOne, Microsoft Defender, CarbonBlack, Cylance, Osquery, Tanium e Qualys instaladas.
“O caminho operacional mais claro é o C2 baseado em REST: o implante faz beacons para um endpoint HTTP, aceita tarefas criptografadas e envia os resultados dos comandos de volta para a mesma infraestrutura.
Em torno desse núcleo, o payload também inclui suporte para transporte de upload, cifragem de comandos, assinatura de nós, atualizações de payload, gerenciamento de arquivos, execução de shell e gravação de persistência.”
Segundo a StepSecurity, o invasor teria obtido acesso de publicação aos repositórios e usado o próprio pipeline legítimo de release do GitHub Actions do projeto para publicar pacotes com attestations válidas de proveniência OIDC.
O ataque à supply chain não envolveu o roubo de um token do npm.
“Ambos os ataques são comprometimentos de pipeline de CI/CD, não tokens npm roubados nem mantenedores maliciosos”, disse o pesquisador de segurança Rohan Prabhu.
“O invasor enviou commits usando uma identidade git de espaço reservado e deixou que o fluxo de release real de cada repositório fizesse a publicação por meio da integração trusted-publisher do npm via GitHub OIDC.”
“Os pacotes resultantes carregam attestations legítimas de proveniência SLSA, provando apenas que o fluxo autorizado do projeto os produziu, e não que os commits que dispararam o processo eram legítimos.
A proveniência não protege contra uma credencial de publicação comprometida.”
As cinco versões maliciosas já foram removidas do registry do npm.
A orientação é tratar qualquer endpoint que tenha importado ou executado uma dessas versões como potencialmente comprometido.
Ainda assim, a exposição depende de o módulo infectado ter sido carregado como parte de um build ou de um fluxo de trabalho de desenvolvimento.
“Não há script preinstall, postinstall ou install em nenhum dos três arquivos package.json”, disse a StepSecurity.
“Esse dropper é ativado quando o módulo adulterado é carregado com require() durante o uso normal do generator: no momento em que um build ou job de CI realmente chama a biblioteca, e não durante o npm install.”
Publicidade
Nossa audiência é formada por analistas, pentesters, decisores e entusiastas que consomem nossas notícias todo dia pelo Site, Newsletter e Instagram. Fale com quem realmente importa para o seu negócio. Anuncie aqui. Saiba mais...