Conta legítima de desenvolvedor foi usada para publicar versões maliciosas de extensões no Open VSX, com loader voltado a credenciais de macOS, tokens de desenvolvimento e carteiras de criptomoedas.
| Componente | Open VSX Registry e quatro extensões já estabelecidas publicadas pelo autor oorzc. |
| Vetor | Publicação de versões maliciosas por meio de credenciais de publicação comprometidas, possivelmente token vazado ou outro acesso não autorizado. |
| Impacto | Entrega do loader GlassWorm, com rotinas para roubo de credenciais de macOS, dados de carteiras de criptomoedas, tokens npm e artefatos de autenticação do GitHub. |
| Prioridade | Remover versões afetadas dos ambientes, auditar extensões instaladas, rotacionar credenciais de desenvolvimento e procurar comportamento de loader criptografado em estáções de trabalho. |
| Artefatos | Campanha GlassWorm, técnica EtherHiding, uso de Solana memos como dead drop dinâmico e busca por arquivos de carteiras como Electrum, Exodus, Atomic, Ledger Live, Trezor Suite, Binance e TonKeeper. |
| Mitigação | A remoção do marketplace não desinstala extensões já presentes nos editores; a correção exige verificação local e nova versão legítima superior para disparar atualização automática. |
O incidente envolveu o Open VSX Registry, ecossistema usado para distribuição de extensões compatíveis com editores de desenvolvimento. Em 30 de janeiro de 2026, quatro extensões associadas ao autor oorzc receberam versões maliciosas. Essas extensões já existiam como utilitários legítimos havia tempo e somavam mais de 22.000 downloads antes da publicação dos pacotes adulterados, o que aumentou o risco para usuários que confiavam no histórico do publicador e em atualizações automáticas.
A avaliação técnica aponta para comprometimento dos recursos de publicação do desenvolvedor, com hipótese de token vazado ou outro acesso não autorizado à conta. A característica mais relevante é a troca de um modelo baseado em extensões fraudulentas por abuso de identidade legítima. Em vez de depender apenas de typosquatting ou brandjacking, o operador inseriu o malware dentro de um canal já aceito por usuários e fluxos de desenvolvimento, reduzindo sinais óbvios de fraude no momento da instalação ou atualização.
As versões contaminadas foram projetadas para entregar um loader associado à campanha GlassWorm. O código malicioso usa descriptografia em tempo de execução, recupera infraestrutura de comando e controle por meio de EtherHiding e adota Solana memos como mecanismo de dead drop para rotação de endpoints sem republicar extensões. Esse desenho diminui a utilidade de indicadores estáticos isolados e exige resposta baseada em comportamento, integridade de extensão, telemetria de processo e revisão de credenciais acessíveis ao ambiente do desenvolvedor.
A cadeia começa no ponto de confiança do registro: uma extensão legítima recebe uma nova versão publicada por uma conta que aparenta pertencer ao mantenedor real. Para o usuário ou para automações que aceitam atualização de extensões, a alteração pode parecer parte do ciclo normal de manutenção. Depois da instalação ou atualização, o loader embutido entra em operação, descriptografa componentes em tempo de execução e evita deixar toda a lógica maliciosa exposta de forma simples em análise estática.
Antes de executar as etapas de coleta, o malware perfila a máquina comprometida. A execução completa ocorre somente depois de identificar que o ambiente não corresponde a uma localidade russa, padrão observado em famílias associadas a operadores de língua russa que tentam reduzir exposição doméstica. Esse controle de ambiente também pode prejudicar sandboxing básico, porque a carga útil não necessariamente apresenta o mesmo comportamento em qualquer máquina de análise.
O objetivo operacional descrito para a carga inclui roubo de material de autenticação usado em fluxos de desenvolvimento. O malware inspeciona configurações do npm em busca de _authToken e referencia artefatos de autenticação do GitHub. Em um ambiente corporativo, esse tipo de acesso pode alcançar repositórios privados, segredos de CI, automações de release e credenciais que conectam estáções de trabalho a serviços de nuvem. Também há rotinas voltadas a credenciais de macOS e arquivos de carteiras de criptomoedas, incluindo Electrum, Exodus, Atomic, Ledger Live, Trezor Suite, Binance e TonKeeper.
A comunicação de infraestrutura evita depender de um endpoint fixo gravado de forma direta. O uso de EtherHiding e Solana memos como dead drop permite que o operador atualize pontos de staging sem alterar a extensão publicada. Para defesa, isso desloca a análise para sinais como execução de código ofuscado, descriptografia em memória, consultas inesperadas relacionadas ao mecanismo de dead drop e tentativas de acesso a arquivos de autenticação ou carteiras fora do comportamento esperado do editor.
A exposição principal está em estáções de trabalho de desenvolvedores que instalaram ou atualizaram as quatro extensões do autor oorzc durante a janela em que versões maliciosas estiveram disponíveis. Como três extensões ainda estavam disponíveis para download em 2 de fevereiro de 2026 às 6h30 UTC e foram removidas depois, equipes devem assumir que a presença local não depende apenas do estado atual do marketplace. A remoção do registro impede novas instalações pela mesma origem, mas não apaga automaticamente cópias já instaladas em editores.
O risco se estende além da máquina individual porque o malware mira credenciais conectadas ao ciclo de desenvolvimento. Tokens npm, artefatos do GitHub e segredos de automação podem funcionar como ponte para repositórios privados, pipelines, pacotes publicados e serviços de nuvem. O impacto confirmado no material recebido é coleta e tentativa de extração desses artefatos; qualquer comprometimento posterior de ambientes empresariais deve ser tratado como risco condicionado e validado por logs, escopo de permissões e uso real das credenciais.
- Usuários do Open VSX que instalaram ou receberam atualização das extensões do autor oorzc afetadas em 30 de janeiro de 2026 ou depois.
- Estáções macOS com credenciais locais, arquivos de carteiras de criptomoedas ou artefatos de autenticação usados em desenvolvimento.
- Ambientes com tokens npm, autenticação GitHub, segredos de CI ou automações de release acessíveis a partir da estáção do desenvolvedor.
- Instalações locais de extensões que permanecem no editor mesmo após a remoção das versões maliciosas do Open VSX.
A investigação deve começar pelo inventário de extensões instaladas, histórico de atualização e presença das extensões ligadas ao autor oorzc. Como a atualização automática só será substituída quando o desenvolvedor legítimo publicar uma versão superior, confiar apenas no marketplace deixa uma lacuna operacional. Em estáções afetadas, a triagem deve correlacionar o momento da atualização com execução de processos do editor, criação de subprocessos incomuns, leitura de arquivos de configuração de desenvolvimento e acesso a diretórios de carteiras.
Em endpoints, sinais relevantes incluem carregamento de código ofuscado ou criptografado por extensão, execução após perfilamento de localidade, acesso inesperado a configurações npm, leitura de artefatos de autenticação GitHub e tentativa de enumerar diretórios de aplicativos de carteira. Em rede, a busca deve privilegiar padrões de resolução dinâmica de infraestrutura e comunicação associada a dead drops, sem depender apenas de domínios ou endereços fixos. Em identidade e DevOps, a prioridade é verificar uso anômalo de tokens após a data do incidente, especialmente publicação de pacotes, acesso a repositórios privados, execução de pipelines e alterações de segredos.
- Histórico de instalação ou atualização das extensões do autor oorzc no Open VSX em torno de 30 de janeiro de 2026.
- Leitura de
.npmrc, busca por_authTokene acesso a artefatos de autenticação do GitHub por processos ligados ao editor. - Acesso inesperado a arquivos de carteiras Electrum, Exodus, Atomic, Ledger Live, Trezor Suite, Binance ou TonKeeper.
- Comportamento de loader com descriptografia em tempo de execução e busca dinâmica por infraestrutura de comando e controle.
- Uso anormal de credenciais de desenvolvimento após a atualização da extensão, incluindo ações em npm, GitHub, CI e automação de release.
A resposta deve tratar a remoção do Open VSX como contenção parcial. Ação local ainda é necessária: identificar máquinas com as extensões afetadas, remover versões suspeitas dos editores, bloquear reinstalação a partir de caches internos e validar se há uma versão legítima posterior antes de permitir nova distribuição. Em ambientes gerenciados, inventário de extensões deve ser cruzado com EDR, logs de proxy, telemetria de identidade e histórico de alterações de repositórios.
Credenciais expostas ou potencialmente acessíveis pela estáção devem ser rotacionadas com prioridade. Isso inclui tokens npm, autenticações GitHub, segredos de CI, chaves usadas por automação de release e credenciais que tenham escopo para repositórios privados ou contas de nuvem. A rotação deve ser acompanhada por revisão de permissões, revogação de sessões, validação de publicações recentes e análise de alterações feitas por contas de desenvolvedor durante a janela de risco.
Para reduzir recorrência, organizações devem aplicar allowlist de extensões, travar versões aprovadas, monitorar mudanças de publicador e exigir revisão quando extensões antigas receberem atualizações com código ofuscado, acesso a rede ou leitura de material sensível. Registros internos de pacotes e espelhos de extensão precisam preservar histórico suficiente para investigação, porque a retirada de um pacote público pode apagar o caminho óbvio de análise para equipes que não mantêm cópias ou metadados locais.
- Remover manualmente as extensões afetadas dos editores e verificar caches locais ou corporativos antes de reinstalar.
- Rotacionar tokens npm, credenciais GitHub, segredos de CI e credenciais de nuvem acessíveis a partir de máquinas expostas.
- Auditar publicações, commits, execuções de pipeline e alterações de release feitas após 30 de janeiro de 2026.
- Criar regras comportamentais para extensões que leem credenciais, enumeram carteiras, executam loaders criptografados ou buscam infraestrutura dinâmica.
- Restringir atualizações automáticas de extensões em ambientes sensíveis e exigir aprovação para novas versões de fornecedores ou autores críticos.
0 Comentários