Abuso de plugins do Obsidian entrega PHANTOMPULSE em ataques contra finanças e criptomoedas

Campanha REF6598 usa engenharia social, cofres compartilhados do Obsidian e sincronização de plugins comunitários para acionar loaders, resolver C2 por blockchain e manter acesso remoto em Windows.

Componente	Obsidian, sincronização de plugins comunitários, plugins Shell Commands e Hider, loader PHANTOMPULL e backdoor PHANTOMPULSE em Windows.
Vetor	Engenharia social por LinkedIn e Telegram induz a vítima a abrir um cofre hospedado em nuvem no Obsidian e habilitar manualmente a sincronização de plugins comunitários.
Impacto	Execução de código por funcionalidade legítima do Obsidian, carregamento em memória do PHANTOMPULSE, comunicação C2 via WinHTTP, coleta de telemetria, execução de comandos, upload de arquivos ou capturas de tela e captura de teclas.
Prioridade	Bloquear a habilitação não autorizada de plugins comunitários em cofres recebidos de terceiros, revisar processos filhos do Obsidian e investigar vaults com configurações JSON capazes de acionar comandos.
Artefatos	A cadeia observada usa PHANTOMPULL como loader intermediário no Windows e PHANTOMPULSE como backdoor; no macOS, usa AppleScript ofuscado e resolução alternativa por Telegram.
C2	PHANTOMPULSE resolve o servidor de comando e controle consultando a transação mais recente associada a uma carteira Ethereum codificada no malware.

Resumo técnico

A campanha REF6598 explora confiança operacional, não uma falha clássica de software, para transformar o Obsidian em um canal de acesso inicial. O fluxo começa com abordagem direcionada a pessoas dos setores financeiro e de criptomoedas, primeiro em uma rede profissional e depois em um grupo no Telegram. A conversa é apresentada como se envolvesse uma firma de capital de risco e supostos parceiros discutindo serviços financeiros e soluções de liquidez para criptoativos, criando um cenário plausível para convencer o alvo a acessar um painel compartilhado.

O ponto técnico central é o cofre do Obsidian hospedado em nuvem. A vítima recebe credenciais para abrir esse conteúdo e, em seguida, é induzida a ativar a sincronização de plugins comunitários instalados. Essa opção fica desabilitada por padrão e não pode ser ligada remotamente, o que torna a etapa de persuasão indispensável para a cadeia. Quando a vítima cruza essa fronteira manualmente, configurações maliciosas do cofre passam a acionar funcionalidades legítimas do aplicativo, especialmente o plugin Shell Commands, usado para executar código, e o plugin Hider, usado para ocultar elementos da interface e reduzir sinais visuais de alteração.

Fluxo técnico

No Windows, a cadeia usa comandos acionados pelo Shell Commands para invocar um script PowerShell com função de estágio inicial. O comando operacional em si é omitido, mas o efeito defensivamente relevante é a entrega do PHANTOMPULL, um loader intermediário que descriptografa e inicia o PHANTOMPULSE diretamente em memória. Essa escolha reduz dependência de artefatos executáveis óbvios em disco e desloca a detecção para comportamento de processo, relação pai-filho e leitura de configurações do cofre.

O PHANTOMPULSE é descrito como um backdoor gerado com apoio de inteligência artificial e implementado para acesso remoto em Windows. Depois de iniciado, ele usa a blockchain Ethereum como mecanismo de resolução de C2: a amostra consulta a transação mais recente ligada a uma carteira codificada e extrai dali o endereço de comando e controle. Com o endereço resolvido, a comunicação ocorre por WinHTTP. As capacidades confirmadas incluem envio de telemetria do sistema, recebimento de comandos, transmissão de resultados de execução, upload de arquivos ou capturas de tela e registro de teclas. O contexto também cita um comando elevate, associado à tentativa de elevação para SYSTEM por meio de moniker de elevação COM.

No macOS, a mesma ideia de abuso do cofre do Obsidian aparece com outro caminho de execução. O plugin entrega um AppleScript ofuscado que percorre uma lista de domínios codificada e usa Telegram como resolvedor morto para obter infraestrutura alternativa. Em seguida, o script contata o domínio C2 para baixar e executar uma segunda etapa via osascript. A natureza exata dessa segunda etapa não foi confirmada porque os servidores C2 estavam offline no momento observado. A intrusão relatada não chegou ao objetivo final do operador, pois a atividade foi detectada e bloqueada antes da conclusão.

Superfície afetada

A exposição prática recai sobre usuários que tratam cofres compartilhados do Obsidian como conteúdo confiável, principalmente quando esses cofres vêm de contatos recentes, supostos parceiros comerciais ou conversas migradas para mensageria. A campanha depende de um usuário habilitar a sincronização de plugins comunitários, portanto ambientes que proíbem ou restringem plugins externos reduzem substancialmente a chance de execução. Ainda assim, a técnica é relevante porque usa uma aplicação legítima, assinada e baseada em Electron como processo responsável por entregar a execução, o que pode enfraquecer controles que esperam um binário desconhecido como ponto inicial.

Os alvos descritos estão ligados a finanças e criptoativos, mas a técnica não é limitada a esse setor. Qualquer fluxo corporativo em que usuários aceitem cofres, notas, painéis ou espaços colaborativos de terceiros pode ser exposto se a política local permitir plugins comunitários e se a equipe não monitorar alterações em arquivos de configuração do Obsidian. O payload também viver em arquivos JSON de configuração torna menos eficaz uma defesa centrada apenas em assinatura de antivírus tradicional.

• Usuários de Windows e macOS que abrem cofres do Obsidian recebidos de terceiros.
• Ambientes que permitem a sincronização de plugins comunitários sem aprovação administrativa.
• Estáções em que o Obsidian pode iniciar PowerShell, AppleScript ou processos auxiliares sem alerta.
• Contas de usuários envolvidos em finanças, investimento, liquidez de criptoativos ou análise de negócios.

Hunting e telemetria

A investigação deve começar pela relação entre Obsidian e processos filhos incomuns. Em Windows, o foco defensivo é identificar o Obsidian iniciando interpretadores ou ferramentas de automação, especialmente quando o evento aparece logo após abertura de um cofre recém-sincronizado. Também é relevante correlacionar criação ou modificação de arquivos JSON dentro do diretório do vault com execução subsequente de PowerShell, carregamento em memória e tráfego WinHTTP para endereços que não fazem parte do uso esperado do aplicativo.

Em macOS, a telemetria deve observar execução de AppleScript e osascript originada indiretamente por uso do Obsidian, além de conexões para domínios codificados ou consultas a serviços usados como resolvedores alternativos. Como a campanha usa Telegram como mecanismo de fallback e blockchain Ethereum para resolução em Windows, bloqueios simples por domínio podem não ser suficientes. O hunting deve buscar a sequência completa: abordagem social, entrada em grupo de mensageria, abertura de vault externo, ativação de plugins, alteração de interface e execução de processo.

• Obsidian criando processos como PowerShell, AppleScript ou osascript sem justificativa administrativa.
• Ativação recente de sincronização de plugins comunitários em cofres recebidos fora de canais corporativos.
• Uso dos plugins Shell Commands e Hider em vaults associados a contatos externos.
• Comunicação WinHTTP iniciada após carregamento em memória de um binário ou estágio não reconhecido.
• Tráfego relacionado a resolução de C2 por blockchain ou uso de Telegram como mecanismo de fallback.

Mitigação

A resposta deve priorizar contenção da cadeia de confiança. Organizações que usam Obsidian devem definir política explícita para plugins comunitários, separar cofres internos de cofres recebidos de terceiros e impedir que a sincronização de plugins seja ativada sem revisão. Para equipes que não dependem desse recurso, a medida mais direta é desabilitar plugins comunitários ou limitar sua execução a listas aprovadas. Onde o uso for necessário, plugins capazes de executar comandos devem ser tratados como componentes de alto risco, com revisão de configuração e monitoramento de processo.

Em endpoints já expostos, a triagem deve coletar o vault suspeito, registrar quais plugins estavam habilitados, preservar arquivos JSON de configuração e revisar logs de criação de processos no intervalo em que o cofre foi aberto. No Windows, a análise deve procurar evidências de PHANTOMPULL e PHANTOMPULSE, carregamento em memória, consultas associadas ao mecanismo de resolução por Ethereum e comunicação WinHTTP fora do padrão. No macOS, a revisão deve cobrir AppleScript ofuscado, execução por osascript e tentativas de contato com domínios usados para segunda etapa. Como a campanha depende de persuasão individual, controles técnicos precisam ser acompanhados por orientação específica sobre cofres colaborativos, convites de investimento e migração de conversas profissionais para grupos de mensageria.

• Restringir plugins comunitários do Obsidian e revisar especialmente plugins com capacidade de executar comandos.
• Bloquear ou alertar quando Obsidian iniciar interpretadores, scripts ou processos de automação.
• Isolar a estáção se houver evidência de PHANTOMPULL, PHANTOMPULSE, keylogging, captura de tela ou execução de comandos.
• Revisar cofres compartilhados, arquivos JSON de configuração e alterações destinadas a ocultar elementos da interface.
• Treinar equipes expostas a contatos de investimento e criptoativos para validar convites, vaults e credenciais por canal independente.