Campanha usou o registro npm e CDNs de pacotes para hospedar iscas em HTML e JavaScript que imitavam portais de documentos e autenticação da Microsoft contra equipes comerciais de 25 organizações.
| Componente | Registro npm, CDNs de pacotes e 27 pacotes publicados por seis aliases de npm usados como hospedagem de iscas de phishing. |
| Vetor | As páginas carregavam HTML e JavaScript do pacote em contexto de navegador, sem depender da instalação da dependência pela vítima. |
| Impacto | Roubo de credenciais por fluxos que imitavam compartilhamento seguro de documentos e redirecionavam usuários para autenticação da Microsoft com e-mail pré-preenchido. |
| Prioridade | Restringir e auditar requisições a CDNs de pacotes fora de ambientes de desenvolvimento, reforçar MFA resistente a phishing e monitorar eventos suspeitos após autenticação. |
| Alvos | 25 organizações em setores como manufatura, automação industrial, plásticos, cadeias de polímeros e saúde, com foco em profissionais de vendas, contas e desenvolvimento de negócios. |
| Artefatos | Pacotes continham endereços de e-mail codificados, JavaScript ofuscado ou minificado, campos honeypot ocultos e verificações de interação por mouse ou toque. |
Uma campanha de spear phishing transformou 27 pacotes publicados no registro npm em infraestrutura de hospedagem para iscas executadas no navegador. A operação usou seis aliases diferentes de publicador e mirou principalmente profissionais de vendas e áreas comerciais em organizações próximas de infraestrutura crítica nos Estados Unidos e em países aliados. O abuso não dependia do cenário clássico de supply chain em que um desenvolvedor instala uma dependência maliciosa; o ponto central era usar o ecossistema de distribuição de pacotes como uma camada confiável e resiliente para servir conteúdo de phishing em páginas controladas pelo operador.
Os pacotes entregavam fluxos completos em HTML e JavaScript que simulavam portais de compartilhamento seguro de documentos e, em seguida, conduziam a vítima a uma página de autenticação da Microsoft com o endereço de e-mail já preenchido. Esse detalhe indica personalização do fluxo para indivíduos específicos, e não uma campanha puramente massiva. O material também incluía endereços de e-mail codificados de 25 pessoas ligadas a funções como gerência de contas, vendas e desenvolvimento de negócios em setores de manufatura, automação industrial, plásticos, cadeias de suprimento de polímeros e saúde.
A técnica central consistia em publicar pacotes no npm e aproveitar CDNs de pacotes para carregar os arquivos do pacote diretamente em uma página de phishing. Quando a página era aberta no navegador, o conteúdo embutido no pacote executava a lógica client-side da isca, exibindo um fluxo que imitava acesso a documentos e encaminhando a sessão para a etapa de coleta de credenciais. Esse modelo reduz a dependência de domínios recém-criados para todos os componentes visíveis do ataque e dá ao operador uma forma de migrar para outro alias ou nome de pacote caso parte da infraestrutura seja removida.
O uso de CDNs legítimas de pacotes também cria ruído defensivo: em muitas empresas, requisições para infraestrutura associada a desenvolvimento de software podem parecer normais quando vistas isoladamente. A diferença relevante está no contexto. Acesso a conteúdo de npm a partir de navegadores de usuários comerciais, sessões de webmail, páginas de documentos ou estáções que não fazem parte de fluxos de desenvolvimento merece investigação, sobretudo quando acompanhado de redirecionamentos para páginas de autenticação e parâmetros com e-mails específicos.
Os pacotes incorporavam controles de anti-análise no lado do cliente. Entre eles estavam filtragem de bots, evasão de sandboxes, exigência de interação por mouse ou toque antes de avançar o fluxo e uso de campos honeypot ocultos. Esses campos não eram visíveis para usuários reais, mas poderiam ser preenchidos por crawlers ou sistemas automatizados de análise; quando preenchidos, funcionavam como um sinal para interromper ou alterar o comportamento da isca. O JavaScript também aparecia ofuscado ou fortemente minificado, aumentando a dificuldade de inspeção automática.
Os domínios presentes nos pacotes apresentavam sobreposição com infraestrutura de phishing adversário-no-meio associada ao Evilginx, um kit aberto usado para intermediar fluxos de autenticação. O material analisado não confirma que todos os fluxos usaram captura de sessão ou bypass completo de MFA, mas a sobreposição é suficiente para elevar a prioridade de investigação de eventos pós-autenticação. Quando uma vítima interage com uma isca desse tipo, a resposta defensiva não deve terminar na troca de senha; é necessário revisar sessões, tokens, dispositivos lembrados, regras de caixa postal e tentativas de acesso subsequentes.
A superfície exposta combina três camadas: o ecossistema de pacotes, o tráfego web corporativo e as identidades dos usuários alvo. O registro npm foi usado como ponto de publicação, enquanto CDNs de pacotes atuaram como canal de entrega. A vítima final, porém, não precisava ser desenvolvedora nem executar instalação local. O risco principal recaía sobre usuários comerciais direcionados por e-mail ou por páginas de isca que carregavam os artefatos diretamente no navegador.
A campanha codificou 25 endereços de e-mail ligados a indivíduos em países como Áustria, Bélgica, Canadá, França, Alemanha, Itália, Portugal, Espanha, Suécia, Taiwan, Turquia, Reino Unido e Estados Unidos. Em vários casos, os alvos pareciam estar em localidades diferentes das sedes corporativas, o que é consistente com foco em equipes regionais, gerentes de país e representantes comerciais. A coleta desses contatos não foi confirmada, mas a relação com grandes feiras internacionais dos setores atingidos sugere possível uso de reconhecimento em fontes abertas e páginas públicas de eventos.
- Pacotes publicados no
npmpor seis aliases diferentes, com nomes que podiam ser substituídos caso fossem removidos. - Conteúdo HTML e JavaScript carregado por CDN em contexto de navegador, sem instalação de dependência pela vítima.
- Alvos em manufatura, automação industrial, plásticos, polímeros e saúde, principalmente em funções comerciais.
- Endereços de e-mail específicos codificados nos pacotes para personalização do fluxo de autenticação falso.
A investigação deve começar pela separação entre tráfego legítimo de desenvolvimento e tráfego incomum para CDNs de pacotes. Em ambientes corporativos maduros, acessos a npm e serviços relacionados devem estar concentrados em estáções de engenharia, servidores de build, proxies de dependências e pipelines de CI/CD. Requisições originadas de estáções de usuários de vendas, navegadores comuns, clientes de e-mail ou sessões recém-abertas a partir de links externos indicam um contexto divergente e devem ser correlacionadas com URLs de origem, horários, usuário autenticado e sequência de redirecionamentos.
No endpoint e no proxy, a defesa deve procurar páginas que carreguem bundles HTML e JavaScript de pacotes pouco conhecidos, minificados de forma agressiva ou acessados uma única vez por usuários fora de times técnicos. Em identidade, a trilha mais importante vem após a interação: autenticações em sequência, solicitações de MFA em horários incomuns, criação de sessões persistentes, alteração de métodos de autenticação, acesso de novos países ou dispositivos e atividade em aplicações Microsoft logo depois do clique. Se houver sinais de phishing adversário-no-meio, a revisão precisa incluir tokens e sessões já emitidos, não apenas credenciais estáticas.
A telemetria de navegação também pode revelar controles de anti-análise. Páginas que só avançam após eventos de mouse ou toque, formulários com campos invisíveis, mudanças de comportamento quando acessadas por crawlers e scripts com ofuscação pesada são sinais úteis para triagem. Esses elementos, isoladamente, não provam roubo de credenciais, mas ajudam a diferenciar uma página comum de documento compartilhado de um fluxo feito para evitar sandbox e análise automatizada.
- Requisições a CDNs de pacotes partindo de estáções comerciais ou navegadores sem relação com desenvolvimento.
- Carregamento de HTML ou JavaScript de pacotes recém-publicados, pouco usados ou associados a aliases desconhecidos.
- Redirecionamentos para autenticação da Microsoft com e-mail pré-preenchido após abertura de suposto documento compartilhado.
- Eventos pós-autenticação anômalos, incluindo novo dispositivo, nova localização, sessão persistente ou alteração de método de acesso.
- Páginas com campos ocultos, exigência de interação humana e scripts ofuscados antes da etapa de autenticação.
A resposta deve tratar o caso como abuso de infraestrutura confiável, e não apenas como bloqueio de domínio malicioso. O primeiro passo é criar política clara para uso de CDNs de pacotes: estáções de desenvolvimento e servidores de build podem precisar desse acesso, mas departamentos comerciais normalmente não devem carregar conteúdo arbitrário do npm em páginas web. Quando o bloqueio amplo não for viável, proxies, DNS seguro e gateways web devem aplicar inspeção por contexto, reputação do pacote, idade do artefato, frequência de uso e perfil do usuário.
A autenticação deve ser reforçada com MFA resistente a phishing, especialmente para contas de vendas, gerentes regionais e equipes que lidam com documentos externos. Métodos baseados apenas em aprovação simples ou códigos reutilizáveis são mais frágeis diante de fluxos adversário-no-meio. Além disso, a resposta a um clique suspeito precisa incluir revogação de sessões, revisão de dispositivos confiáveis, análise de regras de encaminhamento e busca por acessos anômalos em aplicações de e-mail, armazenamento e colaboração.
Equipes de AppSec e supply chain devem complementar a defesa com verificação rigorosa de dependências, inventário de pacotes permitidos e observabilidade sobre caches, lockfiles e pipelines. Embora está campanha não dependa da instalação dos pacotes, o mesmo registro também vem sendo usado em outras atividades maliciosas, incluindo pacotes destrutivos em npm, PyPI, NuGet Gallery e índices de módulos Go. Esses pacotes podem atrasar execução, buscar código em tempo de execução e apagar seletivamente repositórios Git, diretórios de código-fonte, arquivos de configuração e saídas de build. A proteção do ecossistema de desenvolvimento continua necessária mesmo quando o incidente imediato usa o registro como hospedagem de phishing.
- Bloquear ou restringir CDNs de pacotes para usuários e redes que não participam de desenvolvimento ou build.
- Criar alertas para acesso a pacotes desconhecidos a partir de navegadores corporativos fora de ambientes técnicos.
- Aplicar MFA resistente a phishing e revisar sessões ativas quando houver suspeita de interação com a isca.
- Revogar tokens, sessões persistentes e dispositivos lembrados de contas potencialmente expostas.
- Auditar dependências, caches e pipelines para pacotes recém-introduzidos, aliases incomuns e lógica executada por hooks de ciclo de vida.
0 Comentários