Uma nova ferramenta open‑source chamada InvisibleJS permite ocultar código JavaScript dentro de arquivos aparentemente vazios usando caracteres Unicode invisíveis, um método que especialistas avisam poder ser abusado em campanhas de malware.
Como funciona
Segundo a descrição pública do projeto, InvisibleJS converte o código‑fonte JavaScript em cadeias binárias e mapeia 0s para Zero Width Space (U+200B) e 1s para Zero Width Non‑Joiner (U+200C). Em seguida um pequeno carregador (bootstrap) decodifica esses caracteres em tempo de execução e executa o payload, de modo que o arquivo fica aparentemente em branco em editores como VS Code, mas produz saída normal quando executado com node hidden.js.
Versões e modos de execução
- Versão 1 (Classic com eval): indicada para CommonJS e ambientes Node.js legados; suporta require e module.exports de forma nativa.
- Versão 2 (Modern com import): direcionada a ES Modules, usa import dinâmico/await para suportar top‑level await e exports, exigindo .mjs ou "type": "module" no package.json.
Vetor de abuso e contexto
O projeto replica provas‑de‑conceito prévias (há referências a implementações desde 2018) que empregam caracteres invisíveis para ofuscar código. O texto da matéria cita casos anteriores de obfuscação com caracteres Hangul usados para esconder binários e observa que técnicas semelhantes já foram aproveitadas em campanhas de phishing para driblar scanners e checagens de depuração.
Evidências e limitações públicas
A implementação pública inclui comandos CLI para ocultar arquivos (por exemplo, node hideV1.mjs -i input.js -o hidden.js e node hideV2.mjs -i input.js -o hidden.js), e demonstra que a execução do arquivo gerado produz saída idêntica ao original apesar da aparência "vazia". A matéria também apresenta uma tabela comparativa entre as versões, apontando diferenças em suporte a CommonJS, ESM e execução síncrona vs assíncrona.
Impacto para detecção e recomendações
Os autores do texto alertam que InvisibleJS “pode amplificar ameaças”, permitindo loaders furtivos em ambientes Node.js e aplicações web, e que a técnica complica a detecção por análise estática. Como resposta, sugerem que equipes de segurança reforcem varreduras conscientes de Unicode e análise comportamental para identificar decodificação/execução em tempo de execução.
O que falta saber
A reportagem observa o caráter dual‑use da ferramenta (experimental vs uso malicioso), mas não apresenta casos verificados de uso ativo em incidentes no campo. Não há indicação, no material corrente, de exploração em larga escala nem de vítimas identificáveis; trata‑se de um alerta técnico com recomendação de mitigação preventiva.
Implicações práticas
- Analistas devem incluir regras que detectem sequências zero‑width incomuns e examinar loaders que realizem decodificação em runtime.
- Equipamentos de proteção e scanners precisam avaliar comportamento em execução (execução dinâmica e criação de processos/node invocations) além da análise textual do arquivo.
- Desenvolvedores e equipes de DevSecOps devem revisar pipelines e políticas de aprovação de código para detectar artefatos “visualmente vazios”.
Fonte: reportagem técnica e repositório público citados na matéria.