Sapphire Sleet: como pacotes npm comprometidos e transações vazias de Ethereum escondem malware

O que é a campanha Sapphire Sleet

Em 29 de julho de 2026, a Amazon Threat Intelligence (ATI) publicou uma análise que relaciona os quatro incidentes ao ator identificado como Sapphire Sleet. O grupo também é conhecido por nomes como BlueNoroff, Stardust Chollima, CageyChameleon e Alluring Pisces .

A Amazon classificou a atribuição com confiança média e descreveu o grupo como financeiramente motivado . A sequência dos incidentes foi a seguinte:

• typo-crypto, em março de 2025: a Amazon avalia que o comprometimento pode ter funcionado como um teste para aperfeiçoar as técnicas usadas posteriormente .
• debug e chalk, em setembro de 2025: os invasores enganaram o responsável pelos pacotes usando um domínio que imitava o npm e, depois, publicaram um script capaz de esvaziar carteiras de criptomoedas. Ao menos 18 versões maliciosas foram identificadas . A estimativa é que o ataque tenha alcançado 10% dos ambientes de nuvem em até duas horas após a publicação .
• axios, em março de 2026: duas versões comprometidas, 1.14.1 e 0.30.4, introduziram uma dependência maliciosa que baixava um trojan de acesso remoto . Na época, a biblioteca registrava mais de 70 milhões de downloads semanais .

O método combinou engenharia social, roubo de credenciais de mantenedores e código gerado ou auxiliado por inteligência artificial, elaborado para dificultar a detecção . Em vez de alterar diretamente a lógica principal dos pacotes, os invasores distribuíram atualizações adulteradas que executavam scripts durante a instalação e podiam roubar credenciais, tokens, chaves de API e ativos digitais .

Como funciona o NullReceiver

Em pesquisas divulgadas entre 2 e 4 de agosto de 2026, analistas da OpenSource Malware documentaram uma técnica de comando e controle (C2) chamada NullReceiver. Ela foi encontrada nos pacotes npm bianira-ui@1.27.0 e fluid-type-ui@2.0.8, que se passam por plugins legítimos do Tailwind CSS e estão ligados à campanha Contagious Interview .

O mecanismo funciona em quatro etapas :

1. O malware traz embutido um endereço de carteira Ethereum específico: 0xa322e5f3d311d3080e6f0121063e9adc2490ef1a .
2. Quando é executado, consulta a blockchain em busca da transação de saída mais recente dessa carteira.
3. Em seguida, lê o endereço de destino de uma transferência com valor zero e sem dados adicionais.
4. Os bytes desse endereço, quando decodificados, correspondem ao endereço IP do próximo servidor de comando e controle.

Na prática, a consulta parece uma atividade comum da blockchain: uma transferência de criptomoeda entre carteiras. Não há domínio suspeito, carga escondida nos dados da transação nem endereço IP fixo no código do malware.

A técnica é descrita como uma evolução do EtherHiding, método que escondia código malicioso em dados de contratos ou transações de blockchain. No NullReceiver, o “segredo” é deslocado para o próprio endereço do destinatário, o que dificulta a análise estática e o bloqueio tradicional por domínio .

O que as empresas de segurança concluíram

As principais empresas de inteligência de ameaças chegaram a conclusões semelhantes, embora com diferentes níveis de confiança:

• A Amazon Threat Intelligence relacionou os quatro comprometimentos à Sapphire Sleet com confiança média, com base em indicadores de C2, código reutilizado, ganchos de pós-instalação e táticas compartilhadas .
• A Microsoft Threat Intelligence atribuiu com alta confiança ao mesmo grupo um ataque contra o ecossistema Mastra, ocorrido em 17 de junho de 2026. Em uma janela de 45 minutos, mais de 140 pacotes maliciosos foram publicados .
• A Microsoft também associou a Sapphire Sleet ao comprometimento do axios e documentou campanhas voltadas a usuários de macOS que usavam iscas relacionadas ao Microsoft Teams .
• A Google Threat Intelligence atribuiu o ataque contra o axios ao mesmo ator, rastreado pela empresa como UNC1069 .
• Órgãos de cibersegurança dos Estados Unidos e de países aliados vêm alertando para o uso de comprometimentos da cadeia de fornecimento de software de código aberto em operações norte-coreanas de roubo de criptomoedas .

A TRM Labs estimou que a Coreia do Norte foi responsável por 76% do valor de todos os roubos de criptomoedas atribuídos a ataques em 2026. Esse número, porém, não se refere exclusivamente aos incidentes envolvendo pacotes npm .

Até o momento, não foi localizada nas fontes analisadas uma declaração pública do governo norte-coreano negando especificamente as acusações relacionadas à Sapphire Sleet ou à técnica NullReceiver. Portanto, não é possível afirmar que houve uma negativa oficial sobre essas campanhas em particular.

Por que o ataque preocupa desenvolvedores

O caso mostra por que a cadeia de fornecimento de software não termina no repositório da empresa. Uma biblioteca aparentemente confiável pode ser adulterada na conta de seu mantenedor e executar código malicioso no computador do desenvolvedor, no servidor de integração contínua ou no ambiente de produção.

O NullReceiver amplia o desafio porque não depende de um domínio suspeito ou de um IP gravado diretamente no arquivo malicioso. O bloqueio de domínios, por si só, pode não impedir a resolução do servidor de C2 quando o endereço é obtido dinamicamente por meio de uma blockchain pública.

Entre as medidas recomendadas por pesquisadores e empresas de segurança estão :

• manter um inventário atualizado das dependências e uma lista de materiais de software (SBOM);
• revisar alterações inesperadas em pacotes e monitorar o comportamento durante a instalação e a execução;
• adotar uma janela de quarentena, evitando instalar versões publicadas nas últimas 24 a 72 horas quando o fluxo de trabalho permitir;
• desativar scripts de ciclo de vida, especialmente os de pós-instalação, sempre que possível;
• fixar versões e instalar dependências de forma determinística;
• tratar um pacote comprometido como um risco mais amplo para credenciais e ambientes: isolar sistemas afetados, trocar segredos e acompanhar possíveis atividades posteriores.

A principal lição é direta: a popularidade de uma biblioteca não garante que cada nova versão seja segura. Em ataques de cadeia de fornecimento, a atualização aparentemente rotineira pode ser justamente o momento em que o malware entra no ambiente.