Se abusó de un plugin de Obsidian para distribuir un troyano de acceso remoto

 (cyber.netsecops.io)
1 puntos por GN⁺ 4 시간 전 | 1 comentarios | Compartir por WhatsApp
  • La campaña REF6598 distribuye el RAT PHANTOMPULSE mediante bóvedas compartidas de Obsidian
  • Los objetivos son profesionales de finanzas y criptomonedas en Windows y macOS, atraídos a través de LinkedIn y Telegram
  • La infección comienza cuando se activa manualmente la sincronización de plugins de la comunidad desde una bóveda compartida
  • Los plugins maliciosos Shell Commands y Hider ejecutan scripts, y PHANTOMPULL carga el RAT
  • PHANTOMPULSE consulta la dirección de C2 en transacciones de Ethereum, lo que dificulta su bloqueo

Flujo del ataque

  • Acceso inicial y ejecución

    • La campaña REF6598 abusa de la app de notas Obsidian para distribuir el troyano de acceso remoto (RAT) PHANTOMPULSE, que no había sido documentado previamente
    • Los atacantes se hacen pasar por contactos de capital de riesgo, se acercan a sus objetivos en sitios profesionales de networking y luego trasladan la conversación a un grupo privado de Telegram
    • Con el pretexto de colaborar, inducen a la víctima a unirse a una bóveda compartida de Obsidian alojada en la nube
    • El acceso inicial corresponde a T1566.002 Spearphishing Link de MITRE ATT&CK
    • La infección comienza cuando la víctima activa manualmente dentro de Obsidian la función de sincronización de “Installed community plugins”
    • La bóveda compartida incluye versiones maliciosas de los plugins legítimos de Obsidian Shell Commands y Hider, y la activación de plugins de la comunidad lleva a la ejecución de código
    • El plugin comprometido Shell Commands ejecuta un script malicioso
    • La etapa que induce al usuario a ejecutar un archivo malicioso corresponde a T1204.002 Malicious File

  • Etapas de infección en Windows y macOS

    • En Windows, el plugin malicioso ejecuta un script de PowerShell, y ese script deja caer el loader PHANTOMPULL
    • En macOS, un procedimiento similar se realiza mediante AppleScript
    • Después, PHANTOMPULL descifra y ejecuta la carga final, el RAT PHANTOMPULSE
    • PHANTOMPULSE ejecuta la carga final directamente en memoria para evadir la detección basada en archivos, lo que se relaciona con T1055 Process Injection

Capacidades de PHANTOMPULSE y método de C2

  • Una vez activado, PHANTOMPULSE puede capturar pulsaciones de teclas, tomar capturas de pantalla, exfiltrar archivos y ejecutar comandos arbitrarios
  • La comunicación C2 está diseñada de una forma que corresponde a T1102.002 Bidirectional Communication
  • PHANTOMPULSE consulta las transacciones más recientes de una dirección de billetera codificada de forma estática
  • La dirección IP del servidor C2 está incluida dentro de esos datos de transacción, y el malware la usa para identificar el servidor desde el cual recibirá comandos
  • Este método ofrece un mecanismo de descubrimiento de direcciones C2 descentralizado y resistente a la censura, lo que dificulta interrumpir la infraestructura maliciosa

Impacto

  • Si la infección tiene éxito, los atacantes pueden obtener acceso total al sistema de la víctima
  • Los profesionales del sector financiero y de criptomonedas pueden sufrir el robo de datos corporativos sensibles, propiedad intelectual, estrategias de trading, claves de billeteras cripto y credenciales de exchanges
  • La estructura dirigida tanto a Windows como a macOS amplía el rango de víctimas potenciales
  • El uso de C2 basado en blockchain muestra un alto nivel de sofisticación y dificulta la interrupción de la infraestructura de la amenaza

Indicadores de detección

  • Procesos

    • Obsidian.exe
    • Se debe monitorear si Obsidian genera procesos hijo como powershell.exe, cmd.exe u osascript

  • Patrones de línea de comandos

    • powershell -ExecutionPolicy Bypass
    • La ejecución de PowerShell iniciada desde una aplicación no estándar como Obsidian es una señal sospechosa

  • Tráfico de red

    • Se deben monitorear conexiones salientes desde procesos no esperados hacia nodos o gateways de la blockchain de Ethereum
    • Estas conexiones pueden indicar que PHANTOMPULSE está intentando resolver la dirección de C2

  • Rutas de archivo

    • [Vault]/.obsidian/plugins/
    • Se debe verificar si se crean o modifican archivos en el directorio de plugins de Obsidian fuera del marketplace oficial de plugins

Detección y respuesta

  • Monitoreo de procesos: se necesitan reglas de EDR que detecten y alerten cuando el proceso de Obsidian ejecute intérpretes de línea de comandos como powershell.exe, cmd.exe, bash u osascript
  • Capacitación de usuarios: los usuarios de industrias de alto riesgo deben conocer los riesgos de ingeniería social y del abuso de funciones de herramientas colaborativas como bóvedas compartidas y plugins
  • Control de aplicaciones: cuando sea posible, se deben usar políticas de control de aplicaciones para restringir la instalación y ejecución de plugins de la comunidad no aprobados en apps como Obsidian
  • Monitoreo de red: se deben vigilar consultas DNS anómalas o conexiones IP directas relacionadas con servicios de blockchain desde endpoints donde esa actividad no sea esperada

Medidas de mitigación

  • Verificación de plugins de la comunidad: se debe tener especial cuidado al habilitar plugins desarrollados por terceros o por la comunidad en cualquier aplicación; deben instalarse solo desde marketplaces oficiales de confianza y revisarse sus permisos
  • Deshabilitar la sincronización automática de bóvedas no confiables: no se debe habilitar la sincronización de plugins al conectarse a bóvedas de Obsidian provenientes de fuentes desconocidas o no confiables
  • Principio de mínimo privilegio: aplicaciones como Obsidian deben ejecutarse con permisos de usuario estándar y no con privilegios de administrador para limitar el impacto de una intrusión
  • Seguridad de endpoint: se deben desplegar soluciones actualizadas de EDR y antivirus para detectar y bloquear ejecuciones sospechosas de scripts y técnicas de inyección de procesos

Mapeo de mitigaciones de MITRE ATT&CK

  • User Training
    • Capacitar a los usuarios para reconocer tácticas de ingeniería social y sospechar de invitaciones de colaboración no solicitadas es una defensa clave contra este vector de ataque
  • Execution Prevention
    • Usar control de aplicaciones para impedir que apps como Obsidian ejecuten scripts como PowerShell puede romper la cadena del ataque
    • Mapeo D3FEND: D3-EAL
  • Software Configuration
    • Configurar la aplicación para deshabilitar la instalación de plugins de terceros o exigir una aprobación estricta reduce la superficie de ataque
    • Mapeo D3FEND: D3-ACH

Referencias

Lecturas relacionadas

1 comentarios

 
GN⁺ 4 시간 전
Comentarios en Hacker News

  • Soy el CEO de Obsidian. Pronto saldrá una gran actualización sobre la seguridad de los plugins, y creo que podrá resolver muchas de las preocupaciones planteadas en este hilo
    Es un problema difícil, pero estamos trabajando en ello. Dicho eso, el título lleva a confusión. Este artículo trata sobre un ataque de ingeniería social en el que el usuario tiene que rechazar manualmente varias advertencias de seguridad de Obsidian y, hasta donde sé, está al nivel de prueba de concepto; no he visto reportes de daños reales

    • Llevo años diciendo que los plugins no son seguros. Recuerdo claramente que me atacaron en Discord cuando dije que los plugins tenían acceso a todo el disco. Ya es demasiado tarde
    • Entonces, ¿ahora habrá una opción para mover la carpeta .obsidian fuera del vault aunque los plugins estén activados, e ignorar por defecto esa carpeta dentro del vault?
    • No sé qué tan difícil sea, pero agregar un diálogo de permisos como en Android ayudaría muchísimo. El 99% de los plugins de Obsidian no necesita acceso a todo el disco ni acceso a Internet
    • Hacer público el código fuente del cliente también aliviaría muchas preocupaciones
    • ¿"rechazar activamente varias advertencias de seguridad" significa ventanas emergentes y cosas así? La mayoría de la gente aprueba eso sin pensarlo mucho
      Creo que, por defecto, los plugins/extensiones deberían ser un poco más difíciles de ejecutar. Entiendo que poner barreras extra antes de usar un plugin genera fricción para el usuario, pero no creo que exista una forma realmente segura de ejecutar código arbitrario no revisado sin sandbox ni otras restricciones

  • Este es un título engañoso. Hace parecer que se trata de otro ataque a la cadena de suministro en el que un plugin legítimo fue comprometido para distribuir malware
    En realidad, la víctima es invitada a colaborar en un vault sincronizado, y dentro de ese vault ya viene incluido un plugin no oficial que entrega el RAT. Es una historia completamente distinta

    • ¿Qué tiene de engañoso?
      Dice: “Novel Campaign Abuses Obsidian Note-Taking App to Target Finance and Crypto Professionals with PHANTOMPULSE RAT”. Es un ataque nuevo, abusa de Obsidian, apunta a un grupo específico y el RAT está dentro del vault, así que parece una descripción correcta

  • Me encanta Obsidian y lo uso todos los días, pero no uso los plugins de la comunidad porque el sistema de permisos no es suficiente
    Espero que algún día los plugins declaren qué permisos necesitan y que eso se le muestre al usuario. Creo que el equipo de Obsidian se está tomando este problema en serio, y tengo curiosidad por ver qué presentan. Les tengo confianza, pero sorprende que desde el principio se haya diseñado sin un mejor sistema de permisos ni sandbox

    • Empecé a usar Obsidian porque me cansé de usar VS Code para ver archivos Markdown. Por suerte no he tenido necesidad de instalar plugins. Viéndolo así, esta parte parece un diseño bastante malo

  • “A las víctimas se les pide activar la función de sincronización ‘Installed community plugins’”
    Obsidian sí tiene protecciones para evitar este tipo de ataque, y lo que pasó es que convencieron a la víctima de ignorarlas. No es más que un caso exitoso de ingeniería social. Como este ataque no explotó una vulnerabilidad de Obsidian ni del sistema de plugins, no me gusta ver que arrastren a Obsidian por títulos así

    • No estoy de acuerdo. https://obsidian.md/help/plugin-security#Plugin+capabilities
      “Debido a limitaciones técnicas, Obsidian no puede restringir de forma confiable los plugins a ciertos permisos o niveles de acceso. Por lo tanto, los plugins heredan el nivel de acceso de Obsidian.”
      Los plugins de la comunidad pueden acceder a los archivos de tu computadora, conectarse a Internet e incluso instalar programas adicionales. Obsidian no tiene ninguna protección, e instalar un plugin equivale a darle acceso total a tu computadora. Era cuestión de tiempo para que pasara algo así, y creo que ya desde 2010 lanzar un sistema de plugins de este tipo era una negligencia injustificable
    • Uso mucho Obsidian y me gusta, pero creo que el valor de esta divulgación está en crear conciencia sobre los plugins y mostrar la ruta de ataque
      Un usuario menos experimentado podría pensar: “Al final solo es una colección de archivos Markdown. Supongo que no tengo que preocuparme mucho por malware”

  • ¿Por qué casi todos los sistemas de plugins están diseñados de forma tan floja? Me pregunto si es porque no existen buenos frameworks para desarrollar plugins con aislamiento/permisos de verdad y entonces el trabajo se vuelve enorme, o si es porque no se conoce bien lo que hace falta y solo aprenden cuando abusan de su sistema. ¿Son ambas cosas, o hay otra razón?

    • En el fondo hay una compensación entre funcionalidad y seguridad. Puedes darles a los usuarios capacidades potentes para que hagan cosas geniales, o puedes quitar casi todas las capacidades significativas y hacerlo seguro. Por lo general, la gente prefiere funcionalidad sobre seguridad
      Otro problema es que la seguridad es difícil, mientras que dar acceso general y agregar algunas protecciones básicas es fácil
    • Hay que definir el framework de seguridad y los componentes que todos los plugins necesitarán, y luego diseñarlos, implementarlos, validarlos y mantenerlos; eso toma tiempo
      Es mucho más fácil simplemente saltarse esa parte. O sea, sí, es demasiado trabajo, y más precisamente hace falta un liderazgo centrado en seguridad que entienda que este trabajo es mucho, pero es lo correcto
    • Supongo que se debe a la falta de recursos para diseñar una interfaz adecuada sobre el stack web. Este tipo de software está hecho con frameworks JS de alto nivel, así que por defecto suele tener malos patrones de flujo de datos y muchas veces solo sigue lo que es posible hacer en la práctica en lugar de un diseño intencional
      Para diseñarlo de forma intencional, tal vez haya que bajar capas de abstracción y mantener forks personalizados del framework en cuestión. Así que probablemente diseñaron los plugins como si instanciaran una librería pasándole parte del contexto que usa la app. Al final, es la forma más simple que funciona. El hack que se hizo público no habla de una “vulnerabilidad” específica, pero los plugins de Obsidian siempre han estado en modo dios, y el atacante solo engañó a la gente para que los usara. Da risa que, después de unas cuantas ventanas emergentes, haya básicamente ejecución remota de código esperando, y al final igual le echen la culpa al usuario. Los desarrolladores deberían avergonzarse
    • Incluso los plugins del navegador Chrome tienen problemas de seguridad parecidos. Y eso con miles de millones de dólares y muchos desarrolladores muy inteligentes detrás
      Es parecido a crear una App Store dentro de una app. Apple App Store reduce las apps maliciosas limitando de forma muy estricta quién puede publicar qué, y también poniendo barreras de pago
    • ¿Por qué un sistema de plugins tendría que implicar automáticamente un sandbox?

  • Aunque sea ingeniería social, si el diseño del sistema de plugins permite algo así, entonces esta plataforma es totalmente inutilizable como herramienta compartida
    Es bueno saberlo, pero para mí esto no es tanto “si vas a usar un vault compartido de Obsidian, tienes que mantener bien esta configuración”, sino más bien “nunca aceptes un vault compartido de Obsidian y exige una exportación en texto plano”

  • Cuando recién empecé a usar Obsidian, los videos de YouTube que vi recomendaban usar plugins de la comunidad. Incluso con estas advertencias, probablemente habría activado los plugins de la comunidad
    Un desarrollador de plugins que al principio actúa de buena fe podría volverse malicioso después, y el usuario no tiene forma de saberlo. Soy desarrollador y, aun conociendo estos riesgos, creo que igual habría activado la opción de plugins de la comunidad, así que quizá solo tenga una alta tolerancia al riesgo. Espero ser minoría y que no sea el comportamiento de la mayoría de los usuarios

  • Esto se está extendiendo un poco como una epidemia. No todo ataque o exploit, en especial los ataques de ingeniería social, necesita un nombre al estilo Metal Gear o un sitio web

  • Si lees el contenido, el problema no empezó con un plugin de la tienda de Obsidian, sino con un vault malicioso que indujeron a abrir

  • Yo ejecuto Obsidian con permisos restringidos. Sin acceso a red, sin acceso al sistema de archivos fuera de su propio directorio
    Solo habilito el acceso a red cuando actualizo plugins/temas. Hago lo mismo con otras aplicaciones que pueden ejecutar código no confiable

    • ¿Podrías compartir cómo lo pones en sandbox?