- O pacote Lotusbail é um fork da biblioteca legítima de API do WhatsApp Web, Baileys, e contém código malicioso; ele foi baixado mais de 56 mil vezes no npm ao longo de 6 meses
- Enquanto oferece funções de API que operam normalmente, ele rouba credenciais do WhatsApp, mensagens, contatos e arquivos de mídia e os envia para servidores dos atacantes
- Os dados são enviados após múltiplas camadas de criptografia e ofuscação, incluindo RSA, AES, Base-91 e LZString, o que permite driblar o monitoramento de segurança
- O pacote instala um backdoor que mantém o dispositivo do atacante permanentemente vinculado à conta do WhatsApp do usuário por meio de um código de pareamento embutido
- Este caso mostra a sofisticação crescente dos ataques à cadeia de suprimentos e reforça a necessidade de monitoramento de segurança baseado em comportamento, já que a detecção por análise estática sozinha não é suficiente
Visão geral do pacote Lotusbail
lotusbail é um fork do legítimo @whiskeysockets/baileys e fornece as mesmas funcionalidades da API do WhatsApp Web
- O envio e recebimento de mensagens funciona normalmente, o que aumenta a chance de desenvolvedores instalarem o pacote sem suspeitar de nada
- O pacote esteve publicado no npm por 6 meses e, no momento da escrita, ainda continuava disponível para download
- Por trás da funcionalidade real, havia comportamentos maliciosos ocultos, como roubo de credenciais do WhatsApp, interceptação de mensagens, coleta de contatos e instalação de backdoor
Informações roubadas
- Isso inclui tokens de autenticação e chaves de sessão, histórico completo de mensagens, lista de contatos com números de telefone, arquivos de mídia e documentos e acesso persistente por backdoor
- Todos os dados passam por criptografia antes de serem enviados ao servidor do atacante
Como funciona
Função de disfarce que realmente opera
- A maioria dos pacotes npm maliciosos falha ou é facilmente identificada por código suspeito, mas o Lotusbail se disfarça como uma API que funciona normalmente
- Ele é baseado na biblioteca legítima Baileys, com a função de envio e recebimento de mensagens totalmente implementada
- Com isso, é usada uma técnica de engenharia social que faz os desenvolvedores deixarem de suspeitar de comportamento malicioso em um código que “funciona normalmente”
Roubo e transmissão de dados
- O pacote atua envolvendo o cliente WebSocket que se comunica com o WhatsApp
- Durante a autenticação, ele captura credenciais e, ao receber ou enviar mensagens, duplica todo o conteúdo
- A funcionalidade normal é preservada, e apenas todos os dados passam a ser reenviados em duplicidade para o atacante
- Os dados roubados são transmitidos com criptografia por uma implementação customizada de RSA
- Isso existe separadamente da criptografia de ponta a ponta do próprio WhatsApp e é usado como criptografia para evitar vigilância de rede
- O endereço do servidor não fica exposto diretamente no código, mas escondido dentro de uma string de configuração criptografada
- São aplicadas 4 etapas de ofuscação: manipulação de variáveis Unicode, compressão com LZString, codificação Base-91 e criptografia AES
Instalação do backdoor
- O pacote explora o recurso de código de pareamento de dispositivo do WhatsApp para conectar o dispositivo do atacante à conta do usuário
- Dentro do pacote há um código de pareamento fixo criptografado com AES
- Quando o usuário faz a autenticação, o dispositivo do atacante também é conectado ao mesmo tempo, obtendo acesso persistente à conta
- O atacante pode assumir controle total da conta, incluindo leitura e envio de mensagens, download de mídia e acesso aos contatos
- Mesmo que o pacote npm seja removido, o dispositivo do atacante continua vinculado; para bloquear isso, é preciso desconectar manualmente todos os dispositivos nas configurações do WhatsApp
Técnicas para evitar análise
- O código inclui 27 armadilhas de loop infinito, fazendo a execução parar quando ferramentas de depuração são detectadas
- Ele detecta depuradores, argumentos de processo e ambientes de sandbox para dificultar a análise dinâmica
- Há comentários nas seções maliciosas do código, indicando sinais de um processo de desenvolvimento gerenciado de forma sistemática
Conclusão e implicações de segurança
- A sofisticação dos ataques à cadeia de suprimentos está avançando, e aumentam os casos disfarçados como código plenamente funcional
- Só análise estática e verificação baseada em reputação não bastam para detectar isso; é necessária análise comportamental em tempo de execução (behavioral analysis)
- O caso Lotusbail explora a falha de segurança de “acreditar que o código é seguro só porque funciona” e mostra a importância de construir sistemas de monitoramento de comportamento em runtime
- A equipe de pesquisa da Koi Security identificou ameaças que burlam os processos tradicionais de verificação por meio dessas técnicas de detecção baseadas em runtime
1 comentários
Comentários do Hacker News
É frustrante que, sempre que acontece um incidente de malware, a equipe de segurança responda indo na direção de trancar dados demais
O vazamento de mensagens do WhatsApp foi o gatilho, mas no fim teriam roubado outra coisa
Se você bloqueia o app para que só assinaturas específicas possam ler, também torna impossível fazer backup legítimo ou acessar os dados de forma legítima
É bom que a segurança tenha sido reforçada, mas esse tipo de defesa excessiva que tranca tudo também cria outros problemas
O usuário acessa como se estivesse conectando outro cliente à conta do WhatsApp, e com isso acaba permitindo acesso a todos os dados
Se o WhatsApp oferecesse uma API oficial decente, esse tipo de coisa aconteceria menos
Documentação relacionada: Baileys Wiki
Antes havia mais malware, mas também havia muito mais liberdade e interoperabilidade
Esse tipo de ataque agora parece um resultado previsível
Gerenciadores de pacotes como o NPM, que buscam dependências logo antes do build, são fundamentalmente vulneráveis
O problema é uma cultura que contorna o sistema de controle de versão e, ainda assim, aceita uma enorme quantidade de dependências sem verificação
Não é só no NPM: Cargo, Docker, CI/CD e todo o ecossistema têm problemas parecidos
A estrutura é basicamente “instala pelo nome e pronto”, então a confiança implícita é grande demais
Não existe uma solução clara — não dá para abandonar a colaboração, mas segurança completa também é impossível
No fim, o monstro já está dentro de casa
Mesmo se você apontasse diretamente para uma URL de git, o resultado seria o mesmo
No fim, é um problema estrutural do próprio gerenciamento de dependências
Parece que precisamos de um gerenciador de pacotes padronizado e independente de linguagem
Recursos como verificação de assinatura, garantia de origem e padronização de API seriam essenciais
Como no caso do xz, pacotes comprometidos podem acabar sendo distribuídos do mesmo jeito
Além disso, gerenciadores de sistema demoram a oferecer versões recentes, então não servem bem para desenvolvimento
É por isso que ferramentas como npm, cargo e pip acabam sendo necessárias
Não é exatamente um problema do gerenciador de pacotes, e sim código que nunca foi confiável para começo de conversa
É engraçado que o autor do malware tenha usado nomes de função tão explícitos quanto exfiltrateCredentials
Colocou até detecção de debugger, mas ironicamente não fez ofuscação de código
Vivemos numa era em que até testar malware virou uma forma de desenvolvimento
A expressão “dependência que o desenvolvedor instala sem pensar” é assustadora
A menos que seja uma organização com políticas de segurança rígidas, é difícil impedir isso na prática
No fim, talvez a solução seja simplesmente usar menos npm
Se você referencia por tag, fica exposto a qualquer momento a um ataque à cadeia de suprimentos
O setor funciona com muito mais confiança cega do que parece
Sistemas de deploy automático nem têm margem para “pensar duas vezes”
Seria bom se o JavaScript tivesse uma biblioteca grande e confiável como o Apache Commons
Introdução ao Apache Commons
O pacote lotusbail era um pacote npm malicioso que se passava pela API do WhatsApp Web
Foi distribuído por 6 meses e realizava vários ataques, como roubo de credenciais, interceptação de mensagens e instalação de backdoor
Quem depende do ecossistema JS realisticamente precisa de uma estratégia de mitigação de risco
Foram citados métodos com Docker ou VM
Containerizamos todos os ambientes de desenvolvimento e travamos as dependências em versões fixas
Instalação global proibida, atualização automática proibida, validação manual obrigatória
Para projetos sensíveis, usávamos workstations dedicadas que eram reinicializadas periodicamente
É chato, mas essa é a segurança realista
Ou então sair do ecossistema JS também é uma opção
Seria necessário poder confirmar, no nível do SO ou do Docker, se conexões de rede devem ser permitidas ou não
Ainda compartilha o kernel, mas é suficiente para se proteger dos ataques do ecossistema JS
Se um dia surgir escape de contêiner via npm, aí eu migro para VM
No começo parecia segurança exagerada, mas hoje vejo como algo rápido e estável
Porque nesse intervalo a natureza maliciosa tende a aparecer
Esse pacote era uma falha de segurança desde o princípio
Usava uma reimplementação da autenticação do cliente em vez de uma API oficial, e segredos do usuário eram processados por terceiros
O usuário também deveria ter tido mais cuidado, mas é difícil colocar toda a culpa nele
Só é possível obter acesso à API ao se registrar na “WhatsApp Business Platform”
Se existisse uma API real, isso provavelmente não teria acontecido
O problema é entregar segredos de autenticação a terceiros
Em geral, esse tipo de pacote é instalado por quem quer automatizar a própria conta
Hoje em dia há um excesso de posts de blog gerados por LLM
A qualidade é baixa, mas como o custo é zero, do ponto de vista do marketing isso continua eficiente
A escrita tradicional agora virou legacy
Parece que os ataques à cadeia de suprimentos estão aumentando. Como os desenvolvedores devem reagir?
Varreduras automáticas devem detectar esses padrões e reforçar o processo de validação
Containerização, travamento de dependências, varredura de segurança e atualização adiada são indispensáveis
Instalação global via npm é a pior escolha possível
Use contêineres como rootless podman ou VMs para minimizar o risco