Nova campanha de engenharia social que abusa de plugins do Obsidian distribui um novo trojan
(cyber.netsecops.io)- Foi descoberta uma campanha altamente direcionada que tem como alvo profissionais dos setores financeiro e de criptomoedas, transformando em arma o recurso de vault compartilhado do app de notas Obsidian e distribuindo um novo trojan de acesso remoto (RAT) até então não documentado
- Os atacantes se passaram por investidores de venture capital no LinkedIn e no Telegram para construir confiança e, depois, atrair as vítimas para um vault compartilhado malicioso do Obsidian
- Quando a vítima aprova manualmente a sincronização de plugins da comunidade, o código malicioso é executado e o loader PHANTOMPULL é instalado via PowerShell no Windows e via AppleScript no macOS
- O RAT PHANTOMPULSE extrai dinamicamente o endereço do servidor C2 a partir de dados de transações na blockchain Ethereum, ganhando alta resistência aos métodos tradicionais de takedown
- Trata-se de um ataque cross-platform que oferece suporte a Windows e macOS, permitindo controle remoto abrangente, incluindo captura de teclas, screenshots, exfiltração de arquivos e execução arbitrária de comandos
Visão geral da ameaça
- Esse ataque, designado como REF6598, é uma campanha de engenharia social em múltiplas etapas
- O agente da ameaça aborda os alvos em sites de networking profissional se passando por investidor de venture capital e depois move a conversa para um grupo privado no Telegram
- A principal isca é um convite de colaboração por meio de um vault compartilhado do Obsidian hospedado na nuvem
- Quando a vítima abre o vault compartilhado, é induzida a ativar o recurso de sincronização de "Installed community plugins"
- Essa aprovação precisa ser feita manualmente, e esse é o gatilho central da infecção
- Ao ativar, são executadas versões maliciosamente adulteradas de plugins legítimos incluídos no vault compartilhado ('Shell Commands', 'Hider')
Análise técnica
- A cadeia de ataque difere ligeiramente entre Windows e macOS, mas segue o mesmo princípio
- Acesso inicial (T1566.002): via engenharia social no LinkedIn/Telegram, a vítima é levada a abrir um vault compartilhado malicioso do Obsidian
- Execução (T1204.002): o usuário é manipulado para ativar plugins da comunidade no Obsidian, executando scripts maliciosos por meio do plugin 'Shell Commands' adulterado
- Staging: no Windows, um script PowerShell é executado para instalar um loader chamado PHANTOMPULL; no macOS, um processo semelhante ocorre via AppleScript
- Entrega do payload: o loader PHANTOMPULL faz o carregamento direto em memória do payload final, o RAT PHANTOMPULSE, evitando a detecção baseada em arquivo (injeção de processo T1055)
- Comunicação C2 (T1102.002): o PHANTOMPULSE consulta a blockchain Ethereum em busca da transação mais recente de um endereço de carteira hardcoded para extrair o endereço IP do servidor C2
- O endereço IP fica embutido nos dados da transação, implementando uma comunicação C2 descentralizada e resistente à censura
- Uma vez ativado, o PHANTOMPULSE consegue capturar teclas digitadas, tirar screenshots, exfiltrar arquivos e executar comandos arbitrários
Avaliação de impacto
- Em caso de comprometimento bem-sucedido, o atacante obtém acesso completo ao sistema da vítima
- Para profissionais dos setores financeiro e de criptomoedas, há risco de roubo de dados corporativos sensíveis, propriedade intelectual, estratégias de trading, chaves de carteiras de criptomoedas e credenciais de autenticação de exchanges
- A característica cross-platform amplia o alcance potencial do dano
- O C2 baseado em blockchain demonstra alto nível de sofisticação, tornando muito difícil bloquear a infraestrutura da ameaça
Indicadores de observação cibernética para detecção
- Monitoramento de processos: observar se
Obsidian.execria processos filhos comopowershell.exe,cmd.exe,osascript - Padrões de linha de comando:
powershell -ExecutionPolicy Bypass— detectar execuções suspeitas de PowerShell iniciadas por aplicações não padrão como o Obsidian - Tráfego de rede: monitorar conexões de saída para nós ou gateways da blockchain Ethereum vindas de processos inesperados (possível tentativa do PHANTOMPULSE de obter o endereço C2)
- Caminhos de arquivo: monitorar criação ou modificação de arquivos no diretório
[Vault]/.obsidian/plugins/, especialmente alterações fora do marketplace oficial de plugins
Detecção e resposta
- Análise de processos (D3-PA): implementar regras de EDR que detectem e alertem quando o processo do Obsidian gerar interpretadores de linha de comando (
powershell.exe,cmd.exe,bash,osascript) — esse é um comportamento bastante incomum - Treinamento de usuários: educar profissionais de setores de alto risco sobre os perigos da engenharia social e as táticas de abuso dos recursos de vault compartilhado e plugins
- Controle de aplicações (D3-EAL): sempre que possível, aplicar políticas de controle de aplicações que restrinjam a instalação e execução de plugins da comunidade não aprovados em aplicações como o Obsidian
- Monitoramento de rede (D3-NTA): observar se consultas DNS anômalas relacionadas a serviços de blockchain ou conexões IP diretas ocorrem em endpoints onde isso não é esperado
Medidas de mitigação
- Verificação de plugins da comunidade: é necessário extremo cuidado ao ativar plugins desenvolvidos por terceiros ou pela comunidade em qualquer aplicação; instale apenas plugins confiáveis do marketplace oficial e revise obrigatoriamente as permissões
- Desativar sincronização automática de vaults não confiáveis: ao se conectar a vaults do Obsidian vindos de fontes desconhecidas ou não confiáveis, não ative a sincronização de plugins
- Princípio do menor privilégio: execute aplicações como o Obsidian como usuário padrão, e não com privilégios de administrador, para limitar o impacto em caso de comprometimento
- Segurança de endpoint: implantar soluções atualizadas de EDR e antivírus para detectar e bloquear execuções suspeitas de scripts e técnicas de injeção de processo
1 comentários
Comentários do Hacker News
Sou o CEO do Obsidian. Uma grande atualização sobre segurança de plugins vai sair em breve, e acho que vai resolver muitas das preocupações levantadas neste tópico
É um problema difícil, mas estamos trabalhando nisso. Dito isso, o título induz ao erro. Este post trata de um ataque de engenharia social no qual o usuário precisa rejeitar manualmente vários avisos de segurança do Obsidian e, até onde eu sei, está no nível de prova de conceito, sem relatos de vítimas reais
.obsidianpara fora do vault e ignorar por padrão essa pasta dentro do vault?Acho que plugins/extensões deveriam, por padrão, ser um pouco mais difíceis de executar. Entendo que uma barreira extra antes de usar plugins cria atrito para o usuário, mas realmente não acho que exista uma forma de executar com segurança código arbitrário não revisado sem sandbox ou outras restrições
Esse é um título enganoso. Faz parecer outro ataque de cadeia de suprimentos em que um plugin legítimo foi comprometido e passou a distribuir malware
Na realidade, a vítima é convidada para colaborar em um vault sincronizado, e esse vault já contém um plugin não oficial preparado para entregar o RAT. É uma história completamente diferente
Está escrito: “Novel Campaign Abuses Obsidian Note-Taking App to Target Finance and Crypto Professionals with PHANTOMPULSE RAT”. É um novo ataque, abusa do Obsidian, mira um grupo específico, e o RAT está no vault, então parece uma formulação correta
Gosto muito do Obsidian e uso todo dia, mas não uso plugins da comunidade porque o sistema de permissões não é suficiente
Espero o dia em que plugins vão declarar quais permissões precisam, e isso será mostrado ao usuário. Acho que a equipe do Obsidian vai tratar esse problema com seriedade e estou curioso para ver o que vão lançar. Eu confio neles, mas é surpreendente que tenha sido projetado assim desde o começo, sem um sistema melhor de permissões e sandbox
“A vítima é instruída a ativar a função de sincronização ‘Installed community plugins’”
O Obsidian tem mecanismos de proteção para impedir esse tipo de ataque, e a vítima foi convencida a ignorá-los. Foi apenas um caso bem-sucedido de engenharia social. Como esse ataque não explorou uma vulnerabilidade do Obsidian nem do sistema de plugins, não gosto de ver o Obsidian ser arrastado por títulos assim
“Por limitações técnicas, o Obsidian não consegue restringir de forma confiável plugins a permissões específicas ou níveis de acesso. Portanto, plugins herdam o mesmo nível de acesso do Obsidian.”
Plugins da comunidade podem acessar os arquivos do computador, se conectar à internet e até instalar programas adicionais. O Obsidian não tem mecanismo de proteção nenhum; instalar um plugin equivale a conceder acesso total ao computador. Isso era só uma questão de tempo, e eu diria que, por volta de 2010, lançar um sistema de plugins assim já era indefensavelmente descuidado
Usuários menos experientes podem pensar: “É só um monte de arquivos Markdown. Provavelmente nem preciso me preocupar tanto com malware”
Por que quase todo sistema de plugins é projetado de forma tão frouxa? Fico me perguntando se é porque não existe um bom framework de desenvolvimento de plugins que ofereça isolamento/permissões de verdade, então dá trabalho demais, ou se é porque as pessoas simplesmente não conhecem amplamente o que é necessário e só aprendem depois que o próprio sistema é abusado. É os dois, ou há outro motivo?
Outro problema é que segurança é difícil, e dar acesso amplo com alguns guard-rails básicos é fácil
É muito mais fácil simplesmente pular essa parte. Então sim, dá trabalho demais, e mais especificamente exige uma liderança orientada à segurança que entenda que esse trabalho é grande, mas é o trabalho certo a fazer
Para fazer de forma intencional, talvez fosse preciso descer camadas de abstração e manter forks customizados desses frameworks. Então provavelmente os plugins foram projetados como se você estivesse instanciando uma biblioteca e passando parte do contexto usado pelo app. No fim, é a forma mais simples que funciona. O hack divulgado não fala de uma “vulnerabilidade” específica; plugins do Obsidian sempre estiveram em modo deus, e o atacante só enganou as pessoas para usá-los assim. É ridículo culpar o usuário no fim quando há essencialmente execução remota de código esperando atrás de alguns pop-ups. Os desenvolvedores deveriam ter vergonha
É parecido com criar uma app store dentro de um app. A Apple App Store reduz apps maliciosos impondo limites muito rígidos sobre quem pode publicar o quê e também colocando uma barreira paga
Mesmo sendo engenharia social, se o sistema de plugins é projetado de um jeito que permite isso, então essa plataforma é completamente inadequada como ferramenta de compartilhamento
É bom saber, mas para mim isso se aproxima mais de “nunca aceite um vault compartilhado do Obsidian e exija uma exportação em texto simples” do que de “você só precisa manter essa configuração correta para usar um vault compartilhado do Obsidian”
Quando comecei a usar o Obsidian, os vídeos no YouTube que vi recomendavam usar plugins da comunidade. Mesmo com esse tipo de aviso, eu provavelmente teria ativado plugins da comunidade
Um desenvolvedor de plugin que começou com boas intenções pode se tornar malicioso depois, e o usuário não tem como saber. Mesmo sendo desenvolvedor e conhecendo esses riscos, acho que eu teria ativado a opção de plugins da comunidade, então talvez minha tolerância a risco seja alta. Espero ser minoria e que esse não seja o comportamento da maioria dos usuários
Esse tipo de coisa está se espalhando quase como uma epidemia. Nem todo ataque ou exploit, especialmente ataques de engenharia social, precisa de um nome estilo Metal Gear ou de um site
Lendo o conteúdo, o problema não começou com um plugin da loja do Obsidian, mas com um vault malicioso que a pessoa foi induzida a abrir
Eu executo o Obsidian com permissões restritas. Sem acesso à rede, sem acesso ao sistema de arquivos fora do próprio diretório
Só habilito o acesso à rede ao atualizar plugins/temas. Faço o mesmo com outros aplicativos que podem executar código não confiável