O sussurro das festas: Shai-Hulud 3.0

Tradicionalmente, o período de festas de fim de ano é marcado por congelamentos de código e escalas tranquilas. No entanto, também é uma época preferida por invasores oportunistas. Agentes maliciosos adoram as festas: sabem que, com as equipes de desenvolvimento fora do escritório e os tempos de resposta naturalmente mais lentos, surge uma pequena janela para testar novos exploits sem serem detectados de imediato.

Recentemente, um pesquisador de segurança descobriu uma nova variante contida do Shai-Hulud, apelidada de "The Golden Path" (v3.0). Esta versão traz aprimoramentos técnicos que foram desenvolvidos para superar os métodos de detecção atuais. Embora não se trate de um surto generalizado, tudo indica que é uma atualização técnica que sinaliza a evolução contínua dos agentes maliciosos.

Até o momento, os relatos se limitam a um único pacote, o que sugere uma possível fase de testes, e não uma campanha ativa. Veja o que sabemos sobre esta nova versão e por que estamos acompanhando a situação de perto.

Relatos sobre a nova variante

Em 29 de dezembro de 2025, um pesquisador identificou malware embutido no pacote npm @vietmoney/react-big-calendar (versão 0.26.2). O pesquisador acredita que esta é uma evolução direta da linhagem Shai-Hulud, e não uma imitação. A análise sugere que o código foi ofuscado novamente a partir do código-fonte, em vez de ser modificado diretamente. Embora mantenha o mesmo núcleo, a lógica interna foi aprimorada para ser mais resiliente e compatível com várias plataformas.

As versões anteriores do Shai-Hulud se espalhavam rapidamente, priorizando a propagação acelerada. Em contraste, esta variante parece estar voltando o foco para o aperfeiçoamento da furtividade, com ênfase no refinamento técnico e na estabilidade em várias plataformas. Esta versão funciona como um "patch" para o malware, corrigindo especificamente problemas de compatibilidade anteriores com o Windows e o runtime Bun.

Principais detalhes técnicos:

• Exfiltração direcionada: Segundo o código, os dados deveriam ser exfiltrados para repositórios do GitHub identificados pela descrição: "Goldox-T3chs: Only Happy Girl".

• Melhorias de furtividade: O código traz um tratamento de erros aprimorado, desenvolvido para contornar ferramentas de análise de segurança.

• Escopo limitado: Até o momento, apenas um pacote npm teve seu comprometimento confirmado, o que sugere testes de estabilidade, e não uma infecção em massa imediata.

Por que agora?

É provável que o momento em que esta ameaça surgiu tenha sido escolhido de propósito. Os invasores estão explorando duas vulnerabilidades principais que não têm relação com o código:

1. O fator "férias": Com tomadores de decisão de férias e equipes de resposta a incidentes operando com capacidade reduzida, os invasores buscam implantar e aprimorar seu código com muito menos risco de detecção em tempo real.

2. A transição na segurança: O ecossistema npm está adotando a "publicação confiável" como padrão. Nesses casos, é comum que invasores aproveitem o período de "última hora", quando as medidas de segurança ainda são menos rigorosas, para ampliar seu alcance antes que controles mais rígidos entrem em vigor. Algumas atualizações foram feitas neste mês, incluindo a migração do npm para autenticação baseada em sessão e gerenciamento de tokens da CLI.

Vigilância, não pânico

Embora a descoberta de qualquer nova variante mereça atenção, é fundamental agir com vigilância, não com pânico. No momento, não há evidências de uma campanha ampla de infecção. Em vez disso, observamos movimentos pouco claros de um agente provavelmente sofisticado, que parece estar se preparando para operações futuras.

Nossa estratégia se baseia em decisões ativas e bem informadas. É muito provável que o agente malicioso esteja acompanhando estes mesmos relatos e possa mudar de estratégia, alterando o cronograma de implantação ou modificando as assinaturas dos arquivos para escapar da detecção atual. Como o adversário reage às nossas ações, nossa melhor defesa não é o alarmismo, mas uma postura constante e proativa, considerando que os indicadores de comprometimento (IoCs) podem mudar.

Ações recomendadas

Em vez de depender da análise ativa de nomes de arquivos específicos, que podem mudar amanhã, recomendamos que as equipes verifiquem as proteções estruturais para neutralizar os principais vetores de infecção da ameaça. Essa abordagem de "segurança por padrão" oferece uma camada de proteção que continua eficaz mesmo que o agente atualize suas assinaturas técnicas.

• Desative os scripts de ciclo de vida: Os principais vetores de execução desta cepa são os hooks postinstall e preinstall. Reforce seu ambiente definindo ignore-scripts=true no arquivo .npmrc ou executando as instalações com a flag --ignore-scripts para impedir a execução de código arbitrário durante a instalação.

• Exija instalações somente com o arquivo de lock: Em pipelines de CI/CD, use sempre npm ci em vez de npm install. Assim, o ambiente usa apenas as versões exatas fixadas no arquivo de lock, evitando que a resolução para a versão "mais recente" instale acidentalmente uma atualização comprometida.

• Implemente um período de espera: Se o gerenciador de pacotes oferecer suporte (como o pnpm com minimumReleaseAge), considere adiar a adoção de novas versões de pacotes por 24 a 48 horas. A maioria dos pacotes npm maliciosos é identificada e removida poucas horas após a publicação.

• Audite o tráfego de saída: Como esta variante depende da exfiltração de dados para repositórios externos do GitHub, restringir o acesso à rede dos servidores de build a domínios conhecidos e confiáveis pode interromper a cadeia de exfiltração.

Se esta fase de testes indicar uma mudança em direção a uma campanha mais ampla, ou se o agente atualizar suas técnicas para escapar da detecção atual, publicaremos uma atualização imediatamente. Por enquanto, o reforço estrutural e o monitoramento contínuo continuam sendo nossas ferramentas mais eficazes.