Ataque à cadeia de suprimentos atinge Ethersphere

Um ataque à cadeia de suprimentos de software colocou em risco usuários e desenvolvedores do ecossistema Ethersphere, após criminosos conseguirem utilizar credenciais comprometidas de automação para distribuir versões maliciosas de ferramentas oficiais do projeto. O incidente atingiu o pacote JavaScript @ethersphere/bee-js 13.3.0, publicado no npm, e o aplicativo Swarm Desktop 0.56.2, disponibilizado pelo GitHub.

A gravidade do caso está na forma como os invasores aproveitaram a confiança depositada nos próprios mecanismos de distribuição do projeto. Em vez de convencer usuários a instalar um programa desconhecido, eles utilizaram a infraestrutura legítima de desenvolvimento para publicar arquivos contaminados que aparentavam ser atualizações oficiais. O código malicioso foi preparado para roubar arquivos de carteiras digitais, capturar senhas armazenadas localmente e instalar mecanismos de acesso remoto persistente.

O comprometimento também demonstra que assinaturas, certificados e atestados de proveniência não garantem, isoladamente, a integridade de um software. Quando uma conta autorizada ou um token de CI/CD é comprometido, a própria automação pode transformar código malicioso em uma versão aparentemente confiável, ampliando os riscos para ambientes Linux, macOS e Windows.

Como o ataque à cadeia de suprimentos explorou a automação de CI/CD

A investigação do incidente identificou o abuso da identidade de publicação bee-worker, utilizada pelo projeto Ethersphere em seu processo automatizado de lançamento de versões. Os invasores conseguiram publicar alterações diretamente nos repositórios, sem passar pelo fluxo normal de revisão de código por meio de pull requests.

O primeiro alvo foi o repositório do bee-js, biblioteca JavaScript utilizada para interagir com a rede descentralizada de armazenamento Swarm. Em 8 de novembro de 2026, às 23h59 UTC, a conta comprometida publicou uma alteração identificada pelo commit de2f74e, acompanhada da criação da versão 13.3.0.

A modificação transformou o script generate-version.cjs em um carregador de código remoto e adicionou sua execução ao evento postinstall do npm. Esse mecanismo é particularmente perigoso porque permite executar comandos automaticamente durante a instalação de um pacote, mesmo quando o desenvolvedor não importa diretamente suas funções no projeto.

A publicação ocorreu por meio do fluxo legítimo de GitHub Actions com trusted publishing. Como consequência, a versão recebeu uma atestação de proveniência SLSA válida, associando o pacote ao processo oficial de compilação do projeto.

Esse detalhe é especialmente importante: a proveniência confirmou que o pacote passou pelo fluxo de publicação esperado, mas não conseguiu garantir que o código submetido ao processo era legítimo. A automação confiou em uma identidade que já estava sob controle dos atacantes.

Janela de exposição e alcance do comprometimento

O pacote @ethersphere/bee-js 13.3.0 chegou ao npm em 9 de novembro, aproximadamente às 00h09 UTC, permanecendo disponível por cerca de 75 minutos. A versão maliciosa foi removida por volta das 01h25 UTC, quando o registro voltou a apontar para a versão limpa 13.2.0.

Cerca de 30 minutos depois da primeira publicação, os invasores ampliaram a operação com o lançamento do Swarm Desktop 0.56.2. A versão foi disponibilizada no GitHub aproximadamente às 00h36 UTC, utilizando novamente a identidade comprometida e sem o processo habitual de revisão.

O aplicativo permaneceu disponível por aproximadamente oito horas e meia, até a retirada da versão maliciosa. Segundo estimativas divulgadas por pesquisadores, o bee-js 13.3.0 teve aproximadamente dez downloads, incluindo verificações automatizadas e espelhos de distribuição. O Swarm Desktop 0.56.2 chegou a aproximadamente 65 downloads até as 08h27 UTC, também incluindo pesquisadores de segurança.

Esses números não representam necessariamente o total de máquinas infectadas. Além disso, dependências indiretas com intervalos de versões compatíveis com o bee-js 13.3.0 poderiam introduzir o pacote contaminado em instalações de outras ferramentas do ecossistema.

Anatomia do ataque à cadeia de suprimentos e a persistência no Linux e em outros sistemas

O funcionamento do malware foi dividido em diferentes estágios. O primeiro componente é um pequeno carregador JavaScript que consulta o domínio api.frameworkmetrics[.]xyz e executa o código recebido utilizando os recursos nativos do Node.js.

No caso do bee-js 13.3.0, a execução acontece durante o postinstall. Já no Swarm Desktop 0.56.2, o carregador foi inserido no processo principal da aplicação Electron e é acionado durante a inicialização do programa.

O código utiliza o cabeçalho HTTP X-Ethersphere: 1 para solicitar a carga maliciosa. Também identifica o sistema operacional por meio de process.platform, permitindo que o servidor entregue instruções específicas para Linux, macOS e Windows.

Um aspecto preocupante é que o carregador ignora erros de conexão e tempos limite. Dessa maneira, a instalação pode terminar normalmente, sem apresentar mensagens que alertem o desenvolvedor sobre a atividade suspeita.

Depois de receber o segundo estágio, o malware procura os arquivos de configuração e as credenciais utilizadas pelo Swarm Desktop:

• Linux: ~/.local/share/Swarm Desktop, ou o diretório definido por $XDG_DATA_HOME.
• macOS: ~/Library/Application Support/Swarm Desktop.
• Windows: %LOCALAPPDATA%\Swarm Desktop\Data.

O objetivo é localizar dois arquivos particularmente sensíveis: config.yaml e data-dir/keys/swarm.key.

O segundo contém um keystore Ethereum criptografado, enquanto o primeiro armazena a senha necessária para desbloqueá-lo em texto puro. A combinação dos dois arquivos permite aos invasores recuperar o acesso à carteira do nó Swarm.

Isso representa um risco financeiro direto. Os ativos potencialmente expostos incluem xDAI, xBZZ, fundos de chequebooks e valores associados ao staking. Mesmo que a carteira utilize criptografia, a proteção perde sua efetividade quando a chave e a senha são obtidas simultaneamente.

O backdoor evjawbreaker e o uso de smart contracts como C2

Nos ambientes Linux e macOS, o terceiro estágio instala um backdoor escrito em Go, identificado como evjawbreaker. O executável é armazenado em um diretório oculto chamado ~/.solidity, uma localização escolhida para se misturar aos arquivos e ferramentas que desenvolvedores Solidity poderiam utilizar.

No Linux, o malware cria o serviço de usuário solidity-langsupport-runner.service, apresentado como um componente auxiliar de ferramentas de desenvolvimento Solidity. A inicialização é realizada por um script oculto, .run.py, que mantém o implante ativo mesmo após reinicializações.

No macOS, o mecanismo utiliza um LaunchAgent identificado como com.solidity.langsupport.runner. O malware também remove o atributo de quarentena do executável, facilitando sua execução no sistema.

O funcionamento do backdoor é particularmente perigoso porque oferece um shell remoto. Por meio de uma conexão TLS, o programa recebe comandos de um servidor controlado pelos criminosos, executa instruções em um terminal e devolve os resultados. Ele também possui mecanismos para encerrar a execução quando identifica determinados ambientes de depuração ou máquinas virtuais.

Outro detalhe sofisticado envolve a infraestrutura de comando e controle (C2). Em vez de manter o endereço do servidor diretamente no executável, o evjawbreaker consulta um contrato inteligente na rede Ethereum:

0xf8a900Db50b3331be6B768bA460BB59f3E40C344

Por meio de chamadas a serviços públicos de RPC, o malware obtém o endereço atualizado do servidor de controle. A infraestrutura identificada pelos pesquisadores utilizava o endereço 193.57.9[.]155:4912.

Essa estratégia funciona como um dead drop resolver: o contrato inteligente atua como um ponto de referência que pode ser atualizado pelo operador. Assim, mesmo que um endereço de C2 seja bloqueado, os criminosos podem publicar outro endereço no contrato sem precisar distribuir novamente o malware.

No Windows, a abordagem é diferente. Em vez do backdoor Go, a carga instala um cliente oculto do ConnectWise ScreenConnect, utilizando uma técnica de elevação de privilégios associada ao UACMe, método 39. O procedimento envolve um script PowerShell que tenta obter privilégios administrativos e instala o cliente como serviço do sistema.

A ferramenta legítima é configurada para conectar-se à infraestrutura dos atacantes, com endereço de comunicação 185.232.84[.]169:8041. O serviço funciona com privilégios SYSTEM, permitindo controle remoto amplo sobre a máquina comprometida.

Os pesquisadores também identificaram semelhanças entre a infraestrutura utilizada e uma campanha anterior conhecida como SleepyDuck/EtherDuck, associada à distribuição de extensões maliciosas para desenvolvimento Solidity. Essa relação aponta para possível continuidade operacional, embora a atribuição definitiva dos responsáveis deva ser tratada com cautela.

Medidas imediatas de remediação e verificação de integridade

O primeiro cuidado é compreender que remover o pacote malicioso não significa eliminar a infecção. O código pode ter instalado componentes independentes, roubado credenciais e estabelecido persistência antes mesmo de a instalação terminar.

A recomendação é tratar qualquer máquina que tenha executado o bee-js 13.3.0 ou o Swarm Desktop 0.56.2 como potencialmente comprometida.

1. Identifique instalações afetadas

Desenvolvedores devem procurar referências à versão 13.3.0 nos arquivos package-lock.json, npm-shrinkwrap.json, yarn.lock e pnpm-lock.yaml.

Também é importante verificar dependências indiretas, caches locais do npm, registros privados e logs dos pipelines de CI/CD.

Para procurar referências em projetos Linux:

grep -Rni "@ethersphere/bee-js" \
  package.json package-lock.json yarn.lock pnpm-lock.yaml

A verificação deve incluir também instalações realizadas por ferramentas de terceiros que dependam da biblioteca.

2. Inspecione mecanismos de persistência no Linux

Verifique a existência do diretório oculto e do serviço suspeito:

ls -la ~/.solidity

systemctl --user status \
  solidity-langsupport-runner.service

systemctl --user cat \
  solidity-langsupport-runner.service

Procure também conexões de rede suspeitas e processos executados a partir desse diretório.

ps aux | grep -i solidity

journalctl --user \
  -u solidity-langsupport-runner.service

A presença desses componentes deve ser considerada um indicador relevante de comprometimento. Não execute os binários encontrados para tentar identificá-los.

3. Verifique macOS e Windows

No macOS, inspecione o LaunchAgent:

launchctl list | grep solidity

ls -la ~/.solidity

ls -la ~/Library/LaunchAgents/

No Windows, procure o serviço:

Get-Service |
  Where-Object {
    $_.Name -like "*ScreenConnect*"
  }

Também é necessário examinar os registros de instalação, conexões de rede e eventos relacionados ao PowerShell e à elevação de privilégios.

4. Bloqueie a infraestrutura maliciosa

As equipes de segurança devem procurar conexões com api.frameworkmetrics[.]xyz, especialmente os caminhos /v1/analytics, /v1/electron, /v1/assets/ e /v1/swarm/report.

O endereço 193.57.9[.]155:4912 e o relay 185.232.84[.]169:8041 também devem ser considerados indicadores de comprometimento.

Esses indicadores podem ser incorporados a regras de monitoramento de DNS, firewall, EDR e SIEM. Entretanto, bloqueios de rede não substituem a remoção da persistência nem a recuperação dos sistemas.

5. Revogue credenciais e substitua as carteiras

Se o pacote foi executado em uma máquina de desenvolvimento ou runner de CI, considere expostos todos os segredos que estavam acessíveis ao usuário ou processo de instalação.

Isso inclui tokens do GitHub, credenciais npm, chaves SSH, variáveis de ambiente, senhas e credenciais de assinatura. A rotação deve acontecer a partir de um dispositivo confiável, depois de identificar e isolar os ambientes afetados.

Para usuários do Swarm, a orientação é tratar a carteira antiga como comprometida e transferir os ativos, fundos de chequebook e posições de staking para uma nova chave, criada em um ambiente limpo.

6. Reconstrua os ambientes comprometidos

Quando houver execução confirmada do código malicioso, a alternativa mais segura é reconstruir a máquina utilizando uma imagem confiável, em vez de confiar exclusivamente na remoção manual dos arquivos.

Nos pipelines, desative temporariamente fluxos de publicação suspeitos, revise permissões das contas de automação e investigue os registros de execução do GitHub Actions.

Também é recomendável limpar caches de dependências e impedir que versões comprometidas sejam recuperadas por espelhos internos. O bee-js 13.2.0 é a versão limpa anterior ao incidente, enquanto o Swarm Desktop recebeu a versão de recuperação 0.56.3.

Para instalações npm futuras, a opção --ignore-scripts pode reduzir a exposição a scripts automáticos de dependências, desde que seja compatível com o projeto. Ela não substitui a análise dos pacotes nem impede outros mecanismos de execução.

Conclusões e lições de segurança para pipelines modernos

O comprometimento da Ethersphere evidencia uma fragilidade importante na segurança da cadeia de suprimentos: proteger o código-fonte não é suficiente quando as identidades responsáveis por aprovar, compilar e publicar versões também podem ser comprometidas.

O caso demonstra que mecanismos como GitHub Actions, npm Trusted Publishing, SLSA e assinatura de código precisam ser acompanhados por controles independentes de autorização. Uma atestação válida de proveniência não significa necessariamente que o conteúdo publicado foi revisado ou que a identidade responsável pela publicação estava sob controle legítimo.

Outro problema evidenciado foi a ausência de barreiras efetivas para impedir publicações fora do fluxo normal de revisão. A utilização de contas autorizadas permitiu que alterações maliciosas chegassem aos usuários sem passar pelas verificações esperadas.

Para organizações que mantêm projetos de código aberto, algumas medidas devem ser consideradas prioritárias:

• Proteção de identidades: utilizar autenticação multifator resistente a phishing e restringir privilégios de contas de automação.
• Revisão obrigatória: exigir aprovação independente para alterações em workflows, scripts de publicação e arquivos de configuração.
• Proteção de branches e tags: impedir publicações por identidades não autorizadas e exigir assinaturas verificáveis.
• Segregação de ambientes: evitar que runners de CI tenham acesso desnecessário a credenciais de produção.
• Auditoria contínua: monitorar alterações em workflows, eventos de publicação e atividades incomuns de contas automatizadas.
• Verificação de dependências: analisar pacotes antes da instalação e acompanhar mudanças inesperadas em versões de bibliotecas utilizadas.

O episódio também reforça uma lição para administradores Linux e profissionais de DevOps: a confiança em um repositório oficial não deve substituir a verificação técnica dos artefatos distribuídos.

A distribuição de malware por meio de ferramentas legítimas torna os ataques à cadeia de suprimentos especialmente difíceis de identificar. Quando o invasor controla uma identidade confiável, até mesmo mecanismos de assinatura e publicação automatizada podem ser utilizados contra os próprios usuários.