846 pacotes npm maliciosos: como a campanha Flooding Dropper ameaça equipes de scraping

```html

No dia 5 de agosto de 2026, pesquisadores da Sonatype registraram no npm uma campanha chamada Flooding Dropper: 846 componentes maliciosos publicados a partir de dezenas de contas descartáveis. Uma semana depois, o número aumentou — nos dados atualizados da OpenSourceMalware, que monitora a mesma campanha sob o nome WEL1DROPPER, já constam 1033 pacotes confirmados. Dentro deles, um carregador multiplataforma que baixa a segunda fase para Windows, macOS e Linux e limpa da máquina do desenvolvedor tudo o que conseguir alcançar: variáveis de ambiente, credenciais, sessões.

Para equipes que vivem de parsing e automação, isso não é "mais uma notícia sobre npm". O stack de scraping é exatamente npm: Playwright, Puppeteer, Crawlee, wrappers sobre agentes proxy, parsers HTML, filas. E na mesma máquina onde tudo isso é instalado por uma equipe, geralmente está um .env com login e senha do pool de proxies, um cookie-jar de sessões e perfis de navegadores anti-detect. Vamos analisar o que exatamente aconteceu e quais as implicações práticas disso.

O que se sabe sobre a campanha

A Sonatype está conduzindo a campanha sob o identificador sonatype-2026-005660 com uma pontuação CVSS de 8.7 e classificação CWE-506 (código malicioso injetado). Sinais característicos que os pesquisadores usaram para agrupar os pacotes:

• Geração automática de nomes. Os nomes são gerados por interpolação de termos repetidos — o relatório menciona "bigops" e "bnpl", com exemplos como bigops-api e longas combinações como dolyame-boxy-desktop-bnpl-card-gallery. A OpenSourceMalware descreve isso como "AI slop squatting" — um tipo de type-squatting em massa com nomes gerados aleatoriamente em vez de uma falsificação cuidadosa de um pacote popular.
• Versões de um único intervalo. As versões se agrupam em torno de 35.x.y — números anormalmente altos para pacotes sem histórico.
• Distribuição entre contas. Cada conta publica um pequeno lote de pacotes, portanto, bloquear um editor não interrompe a operação.

A mecânica de execução é descrita de maneiras diferentes, e essa diferença é importante. A Sonatype afirma que o código é acionado "na instalação ou importação" do pacote. A OpenSourceMalware esclarece: parte das amostras opera sem os hooks de ciclo de vida clássicos e exige que o desenvolvedor conecte o pacote manualmente através de require(). A conclusão prática é uma: apostar apenas em --ignore-scripts não vai te salvar — se a dependência realmente for importada no código, a carga útil será executada.

Como a segunda fase é entregue

O carregador baixa a carga útil via HTTPS de um host aleatório de uma lista embutida — segundo dados do The Hacker News, os pontos de entrega eram três domínios no Cloudflare Workers. Se o download direto falhar, um canal de backup é ativado: a carga útil é coletada de registros DNS TXT do domínio wel1.ru com subdomínios de plataforma (sdk.dl, ext.dl, pkg.dl, net.dl). Ou seja, o filtro de saída por domínios HTTP é contornado por consultas DNS comuns — e essas são raramente bloqueadas em redes corporativas.

Em seguida, nas plataformas:

• Windows: patching de ETW e AMSI (ou seja, desativação de telemetria e verificação antivírus de scripts), persistência através de chaves de inicialização automática no registro e tarefas do agendador, arquivos em AppData.
• macOS: os mesmos métodos de evasão, persistência através de LaunchAgent. Na carga do macOS, os pesquisadores encontraram domínios de serviços financeiros russos (tcsbank.ru, cloudpayments.ru) — um sinal de interesse direcionado às sessões bancárias de usuários de língua russa.
• Linux: um binário ELF compactado com UPX, que implanta um agente do framework Sliver — isso já é um canal C2 completo, e não um roubo pontual.

Além disso, um conjunto padrão: verificação de sandbox e depurador, identificação de arquitetura, leitura de variáveis de ambiente, processos em segundo plano desconectados (sobrevivem ao fechamento do terminal) e reflexão da carga na memória, para não deixar arquivos no disco.

Por que isso atinge especificamente as equipes de parsing

O infostealer não distingue entre "importante" e "não importante" — ele coleta tudo que parece ser um segredo. Para um usuário comum, isso significa senhas do navegador e carteiras criptográficas. Para alguém que coleta dados, o conjunto de troféus é diferente e, honestamente, mais saboroso:

• Variáveis de ambiente e .env — aqui quase sempre está o host do proxy, login, senha e parâmetros de sessão (país, cidade, identificador sticky). A exfiltração de variáveis de ambiente é explicitamente mencionada na análise da campanha.
• Cookies e tokens de sessão. Uma sessão roubada é uma forma de contornar o MFA: um cookie por si só é uma prova de que a segunda verificação já foi realizada. Logs com tokens válidos para serviços de trabalho são vendidos em mercados clandestinos a partir de $5.
• Perfis de navegadores anti-detect — a combinação "cookie + impressão digital + proxy", ou seja, uma conta de trabalho pronta que não precisa ser aquecida.
• Tokens de CI/CD, npm e nuvem — acesso não apenas à sua máquina, mas também ao pipeline, de onde é possível enviar suas próprias compilações.

A escala do fenômeno deixou de ser nichada. A SpyCloud, em seu relatório de 2026, contabilizou 18,1 milhões de chaves de API e tokens expostos, obtidos especificamente de logs de malware. Segundo dados da Recorded Future e Flashpoint, em 2025, os infostealers infectaram 11,1 milhões de máquinas e resultaram em 3,3 bilhões de contas roubadas. E no relatório da Sonatype sobre o estado da cadeia de suprimentos de software de 2026, mais de 454.600 novos pacotes maliciosos foram registrados apenas em 2025, totalizando mais de 1,233 milhão de bloqueios — um aumento de 75% ano a ano. O Flooding Dropper não é uma anomalia, mas um episódio comum do fluxo.

O que perde o proprietário da conta proxy

Vou falar separadamente sobre algo que geralmente não é mencionado nas análises de segurança, porque os autores não trabalham com proxies. Credenciais de proxy vazadas não são "perda de senha", mas três problemas de uma vez:

1. Tráfego pago. O tráfego residencial e móvel é cobrado por gigabytes. Um scraper de terceiros usando suas credenciais é sua conta, e você pode notar isso muito tempo depois do que gostaria.
2. Reputação de terceiros em seus IPs. O atacante precisa de uma saída "limpa" residencial para que sua atividade pareça a de um usuário doméstico comum. Seus sites-alvo verão comportamentos suspeitos em sua própria sessão — e bans chegarão às contas que você aquecia há anos.
3. Esclarecimento com o provedor. Do ponto de vista de qualquer provedor normal, o tráfego estava saindo da sua conta, e você terá que se explicar.

O que fazer: mínimo prático

1. Separar ambientes. O stack de scraping deve ser instalado em um contêiner ou VM separada — não na máquina onde estão cookies pessoais, e-mail de trabalho e tokens de produção. Esta é a única medida que funciona mesmo contra pacotes que ainda ninguém conhece.
2. Remover credenciais de proxy do .env próximo ao código. Segredos devem estar em um gerenciador de segredos ou em variáveis de ambiente do runner, e não em um arquivo na raiz do projeto que qualquer módulo importado pode ler.
3. Ativar autenticação por IP onde for possível. Vincular o acesso ao seu servidor desvaloriza a combinação de login/senha roubada: de um endereço desconhecido, simplesmente não funcionará. Como isso é configurado e em quais cenários é adequado, foi discutido no material sobre whitelist de IPs para proxies. Regras gerais para armazenamento de acessos estão no guia sobre armazenamento seguro de credenciais de proxy.
4. Credenciais separadas para cada projeto e limites de tráfego. Se cada script tiver seu próprio acesso com um teto em gigabytes, a vazamento de um não esvazia todo o saldo e se localiza em minutos.
5. Monitorar consumo. Um aumento repentino no consumo de GB sem aumento nas tarefas — o detector de comprometimento mais precoce e mais barato que você possui.
6. Disciplina nas dependências. npm ci a partir do arquivo lock em vez de um install livre, quarentena para novas versões (7–14 dias), verificação da idade do pacote e histórico do editor, espelho interno com allowlist. Um pacote com versão 35.x.y, sem histórico e nome gerado a partir de palavras coladas — é um sinal para parar, e não para instalar.

Se suspeitar que já foi comprometido

As recomendações da Sonatype aqui são extremamente específicas e a ordem delas é fundamental: considerar o host completamente comprometido; buscar os mecanismos de persistência descritos (chaves de inicialização automática e tarefas do agendador no Windows, LaunchAgent no macOS); rotacionar credenciais — npm, GitHub, nuvem, CI/CD — após limpar a máquina, e não antes, caso contrário, novos segredos seguirão o mesmo caminho; verificar arquivos lock, caches de dependências e espelhos internos em busca de cópias preservadas; antes da reinstalação, comparar os nomes dos pacotes caractere por caractere.

Adicione a essa lista o que for necessário: troca de senhas de acessos proxy, revogação de sessões ativas no navegador anti-detect e verificação do histórico de consumo de tráfego das últimas duas semanas. Se o tráfego é comprado por gigabytes — proxies residenciais ou móveis — o relatório de consumo é seu registro de acesso.

Conclusão

O Flooding Dropper é interessante não pela sofisticação, mas pela economia: mil pacotes descartáveis, nomes gerados, contas em lotes — é uma linha de montagem projetada para que alguém instale uma dependência sem olhar. Campanhas individuais podem limpar o registro por semanas, mas o fluxo não vai parar: os números da Sonatype do ano passado não deixam ilusões.

A conclusão prática para quem coleta dados é simples. A máquina do desenvolvedor é o ponto onde convergem todos os seus acessos de uma vez: proxies, contas, sessões, pipeline. Isolar o stack, vincular acessos ao IP, distribuir credenciais entre projetos e monitorar o gráfico de consumo de tráfego. Nenhuma dessas etapas requer esperar que uma nova campanha seja indexada.