.svg?width=185&quality=80&auto=webp&format=auto&cache=true&immutable=true&cache-control=max-age%3D31536000 "Home"){kind=logo}
.svg?width=13&quality=80&auto=webp&format=auto&cache=true&immutable=true&cache-control=max-age%3D31536000 "Top Navigation - Sign in - Icon")
En marzo de 2026, el equipo de Respuesta a Incidentes de Emergencia (EIR) de Sophos investigó un incidente en el que observamos que el grupo de ransomware Interlock utilizaba la herramienta legítima de análisis de memoria para la respuesta a incidentes (IR), Volatility3. El uso de herramientas legítimas en ataques como estos continúa una tendencia lamentable que ya señalamos el año pasado.
Interlock, al que los investigadores de la Unidad de Contramedidas contra Amenazas (CTU) de Sophos identifican como GOLD EMBRACE, apareció en septiembre de 2024. Se le ha detectado en todo el mundo, pero actualmente se centra en objetivos norteamericanos y europeos de los sectores de infraestructuras críticas, sanidad y educación. Practica la doble extorsión: roba datos confidenciales antes de cifrar los sistemas y, a continuación, amenaza con filtrar la información en su «Worldwide Secrets Blog» si no se cumplen sus exigencias. En lugar de funcionar como «ransomware como servicio», Interlock parece ser obra de un pequeño equipo especializado de operadores que desarrolla su propio malware y lleva a cabo sus propios ataques.
Entre las tácticas, técnicas y procedimientos (TTP) más destacadas se incluyen el uso de métodos de ingeniería social al estilo ClickFix, un troyano de acceso remoto (RAT) creado a medida llamado «NodeSnake» o (alternativamente) «Interlock RAT», y una puerta trasera basada en PHP para la persistencia multiplataforma (además de atacar sistemas Windows y FreeBSD). Más recientemente, Interlock ha estado explotando activamente CVE-2026-20131, una vulnerabilidad de día cero de gravedad crítica en el software Cisco Secure Firewall Management Center (FMC).
Resumen de la actividad
La actividad del atacante con Volatility3 tuvo lugar en el dispositivo «Paciente Cero» del cliente (es decir, el primer sistema que el actor malicioso logró comprometer para afianzarse en el entorno del objetivo) antes de que empezáramos a trabajar en el caso. El entorno del cliente incluye tanto servidores gestionados por Sophos como (en aquel momento) endpoints gestionados por Defender, aunque se descubrió que, de hecho, no todos los endpoints tenían activada la protección. «Paciente Cero» era un endpoint gestionado por Defender que ejecutaba Windows 10.
En ese equipo, observamos actividad relacionada con el acceso a credenciales para extraer hash NTLM, hash LM (hash heredados, si estaban habilitados) e información de cuentas de usuario mediante este comando:
- vol.exe -f .\mem.raw windows.hashdump.Hashdump
En un escenario de uso legítimo, cabría esperar que se utilizara este comando como parte de una investigación de DFIR, una evaluación de seguridad o un análisis de malware. Sin embargo, el uso malintencionado de Volatility3 dejaría rastros similares. En este caso, el cliente no tenía constancia de ningún uso legítimo de Volatility3 en su sistema.
El equipo también observó el siguiente comando:
- vol.exe -f .\mem.raw windows.cachedump.Cachedump
Este comando intenta extraer de la memoria las credenciales de dominio almacenadas en caché: pares de nombre de usuario y hash, así como información sobre usuarios del dominio que han iniciado sesión anteriormente.
También vimos cómo el actor malicioso utilizaba WinPmem, una herramienta legítima de adquisición de memoria física desarrollada por Velocidex (la empresa que originalmente creó Velociraptor, ahora propiedad de Rapid7), para recopilar la captura de memoria:
- winpmem_mini_x64_rc2.exe mem.raw
Diario de una cadena de ataque
En este caso, el intervalo entre el acceso inicial y el movimiento lateral hacia el controlador de dominio duró algo más de 26 horas: más que la media, pero muy poco tiempo en términos humanos. Curiosamente, como veremos más adelante, el atacante se tomó un descanso de 24 horas antes de redoblar sus esfuerzos; básicamente, estableció persistencia en el equipo «Paciente Cero», lo dejó en suspenso y volvió al día siguiente con un nuevo plan de ataque.
Acceso inicial | T1189 - Compromiso «drive-by»
El primer día del ataque, un dispositivo de un usuario final fue redirigido, tras una búsqueda en ChatGPT sobre Dynamics 365, a un sitio web de confianza que se cree que estaba comprometido en ese momento con un señuelo de tipo ClickFix. El usuario final estaba buscando una aplicación de software legítima en ese momento, tal y como hemos visto en otros casos en los que se utilizan señuelos al estilo ClickFix.
- hxxps[://]www[.]redactado[.]com/dynamics-365-business-central-capabilities/?utm_source=chatgpt[.]com
Al comienzo del ataque (00d 00:00:00), el dispositivo del usuario final se conectó a un servidor web con reputación maliciosa en la IP remota 64.95.11.22, que apunta a voginc[.]com. El proveedor de alojamiento de esa dirección es BL Networks, también conocido como BLNWX o BitLaunch, que está registrado como empresa en Sheridan, Wyoming. Curiosamente, comparte su dirección comercial con una empresa registrada en la Secretaría de Estado de Wyoming como C2 Operations (America) Inc. y otra llamada C2, LLC: dos de entre muchos miles de empresas representadas por «agentes registrados» en esa dirección.
A las 00d 00:00:05 (es decir, a los cinco segundos), se detectaron indicios de ClickFix cuando se leyó el contenido del portapapeles del dispositivo del usuario final mediante una llamada a la API.
A las 00d 00:00:13, el autor de la amenaza recurrió a un poco de ingeniería social para convencer al usuario de que pegara un comando concreto en el cuadro de diálogo «Ejecutar». Esto ejecutó un comando a través del terminal del dispositivo del usuario final para establecer la persistencia, descargando primero código de PowerShell desde el dominio afshapiro[.]com. Este comando de PowerShell de segunda fase utilizó curl para recuperar una carga útil RAT desde 104.236.109.139 e instaló la carga útil para que se ejecutara al iniciar el sistema. Observamos una técnica de evasión interesante en ese primer comando pegado a mano: utilizaba PowerShell, pero lo hacía especificando la ruta donde se encuentra PowerShell y usando un comodín para llegar hasta allí, con el fin de evitar la detección.
Persistencia | T1547.001 - Ejecución automática al arrancar o iniciar sesión: claves de ejecución del Registro / carpeta de inicio
A las 00d 00:25:41, el actor malicioso instaló un comando malicioso en los puntos de extensibilidad de inicio automático (ASEP) del Registro para que se ejecutara al arrancar, con el fin de mantener la persistencia en el dispositivo.
Discovery | T1069.002 - Descubrimiento de grupos de permisos: grupos de dominio
El día 2, el actor malicioso ejecutó una consulta LDAP (Lightweight Directory Access Protocol) en el dispositivo del usuario final. La información estructural proporcionada por las consultas LDAP serviría de guía para la escalada de privilegios en el siguiente paso y, más adelante, para la adquisición de activos.
Escalada de privilegios | T1055.002 - Inyección de procesos: inyección de ejecutables portátiles
A las 01d 00:37:29, el actor malicioso aprovechó el acceso al dispositivo del usuario final para ejecutar la carga maliciosa zoom.txt, utilizando un proceso de confianza de Microsoft para ejecutar el código arbitrario. Los actores maliciosos usan exploits del kernel para elevar los privilegios de seguridad de los procesos en ejecución. Con privilegios elevados, el proceso afectado podría ahora acceder a archivos confidenciales, garantizar la persistencia y modificar la configuración del sistema.
Escalada de privilegios | T1134.003 - Manipulación de tokens de acceso: creación y suplantación de tokens
A las 01d 00:58:22, el actor malicioso consultó un nombre principal de servidor (SPN), lo que indica la ejecución de un ataque de «Kerberoasting» desde el dispositivo del usuario final para escalar privilegios en el dominio. Se trata de una técnica de post-explotación que se usa para obtener credenciales de una cuenta de servicio de los Servicios de dominio de Active Directory (AD DS). Para llevar a cabo este ataque, los atacantes solicitan un ticket de servicio de Kerberos —conocido como servicio de concesión de tickets (TGS)— utilizando el TGT (ticket de concesión de tickets) de un usuario válido del dominio para un SPN específico que tenga los privilegios que buscan. Esto suele implicar una consulta LDAP previa a AD DS para localizar estas cuentas. Por ejemplo, un atacante podría intentar identificar las contraseñas asociadas a las cuentas, que luego podría usar para moverse lateralmente y acceder a recursos dentro de la organización, como se ve en el siguiente paso.
Movimiento lateral | T1021.001 - Servicios remotos: Protocolo de escritorio remoto
A las 01d 02:19:39, el actor malicioso se movió lateralmente desde el dispositivo del usuario final a un controlador de dominio, aprovechando el inicio de sesión anónimo para llevar a cabo un ataque de rebaja de nivel usando NTLM.
Persistencia | T1053.005 - Tarea programada: Tarea programada
El día 3, el actor malicioso, usando la cuenta de administrador de dominio comprometida, ejecutó la siguiente instrucción de línea de comandos en un servidor de impresión para crear una tarea programada que ejecutaba el malware de persistencia debug.log a través de node.exe:
- Tarea: \Microsoft\Windows\Defrag\ScheduledDefrags
- Comando: «C:\Windows\system32\schtasks.exe» /create /sc DAILY /tn \Microsoft\Windows\Defrag\ScheduledDefrags /tr «C:\Windows\system32\config\systemprofile\AppData\Roaming\ node-v22.11.0-win-x64\node.exe C:\Windows\system32\config\systemprofile\AppData\Roaming\node-v22.11.0-win-x64\debug.log" /st 23:30 /ru system
En ese momento, y durante los días siguientes hasta que nos enteramos del incidente y lo contuvimos, el actor malicioso ya se había puesto manos a la obra. Encontramos pruebas de extracción de credenciales (incluidas las de AWS), acceso a archivos confidenciales, creación de nuevas cuentas de administrador de dominio, manipulación de Defender en los endpoints y mucho más. Al final, los datos acabaron filtrándose y el cliente se quedó sin acceso a sus hipervisores.
Protecciones y medidas de mitigación
Los IOC relevantes para este incidente se detallan a continuación y están disponibles en formato .csv en nuestro GitHub:
| Hallazgo | Detección |
| node.log (malicious Java payload) | JS/Agent-BLXU |
| Win64.exe (the ransomware payload) | Troj/Ransom-HKG |
| dll.dll (NtlmThief credential harvester; found truncated) | Troj/Ilocrypt-A |
| browser-updater[.]com (C2 domain) | malware/repository |
| hxxp://216.203.20[.]36/debug[.]log (C2 domain) | malware/repository |
| voginc[.]com | malware/repository |
El repositorio afshapiro[.]com mencionado anteriormente ha sido retirado de la red desde los sucesos que se describen en esta entrada.
Nuestra política de control de aplicaciones incluye Volatility, y los clientes pueden elegir si permiten o no la actividad de Volatility en sus dispositivos gestionados. Además, Sophos cuenta con una detección que habría identificado la actividad de «kerberoasting» si el dispositivo de origen hubiera tenido activadas las protecciones de Sophos (como se ha mencionado antes, los endpoints ejecutaban otro producto en el momento del incidente; la actividad se produjo en el propio endpoint). Animamos a todos los lectores, independientemente de los productos de seguridad que utilicen, a que comprueben que los servicios de detección en los endpoints están presentes en todos los servidores y endpoints, y que el servicio está correctamente instalado y configurado.
Al inicio de la investigación, el equipo de TI del cliente creía que había copias de seguridad disponibles para restaurar los sistemas afectados. Resultó que no era así. La organización tampoco contaba con documentación de red actualizada ni con un inventario completo de sus activos de TI, lo que dificultó determinar qué debería haber estado presente en los entornos virtuales gestionados por los hipervisores afectados. Esa documentación no habría evitado que se produjera el ataque, pero habría facilitado y acelerado mucho más la mitigación y la vuelta a la normalidad.
Del mismo modo, es importante realizar auditorías periódicas de las políticas; incluso las políticas de control de aplicaciones mejor diseñadas necesitan mantenimiento. Estas tareas de supervisión, aburridas pero importantes, permiten actuar más rápido cuando surgen problemas y pueden ayudar a acelerar la vuelta de la organización a su funcionamiento normal.
Conclusión
Para este cliente, el revuelo y las interrupciones causadas por este ataque le llevaron a pasarse a la protección de endpoints de Sophos y a reconstruir su entorno virtual (del que se quedaron bloqueados, lo que hizo inevitable la reconstrucción). Como su entorno de Active Directory se vio muy afectado, también decidieron migrar ese sistema a Entra (Azure AD), con todo lo que eso conlleva.
Desde mediados de 2024, Interlock ha evolucionado hasta convertirse en una amenaza polifacética, cada vez más dispuesta a adaptar sus técnicas y a buscar objetivos de gran envergadura. Los operadores se han mostrado bastante agresivos a la hora de incorporar nuevas técnicas y explotar vulnerabilidades recientes: las pruebas indican que Interlock ya estaba aprovechando el día cero CVE-2026-20131 de Cisco dos semanas antes de que Cisco lo reconociera. El uso de herramientas legítimas como Volatility3 y WinPmem demuestra que esta amenaza sigue evolucionando.
Agradecimientos
Robert Weiland, AJ Raiola, Nigel Weber, Louai Abboud y Andrew Ludgate han aportado sus conocimientos a este informe. Un agradecimiento especial al equipo DFIR de Sophos, el compañerismo y la colaboración en esta investigación han sido increíbles.