Los operadores del ransomware Ryuk vuelven a hacer de las suyas. Después de un largo período de silencio, identificamos una nueva campaña de spam vinculada a los actores de Ryuk, parte de una nueva ola de ataques. Y a finales de septiembre, el equipo de Respuesta Gestionada a las Amenazas de Sophos ayudó a una organización a mitigar un ataque de Ryuk, proporcionando una visión de cómo han evolucionado las herramientas, técnicas y prácticas de los actores de Ryuk. El ataque forma parte de una reciente ola de incidentes de Ryuk vinculados a recientes campañas de phishing.
La banda Ryuk, detectada por primera vez en agosto de 2018, ganó notoriedad en 2019, exigiendo rescates multimillonarios a empresas, hospitales y gobiernos locales. En el proceso, los operadores del ransomware sacaron más de 61 millones de dólares solo en Estados Unidos, según cifras de la Oficina Federal de Investigación. Y eso es solo lo que se informó; otras estimaciones sitúan la recaudación de Ryuk en 2019 en cientos de millones de dólares.
A partir del comienzo de la pandemia mundial de COVID-19, vimos una pausa en la actividad de Ryuk. Se especulaba con que los actores de Ryuk habían pasado a una versión renombrada del ransomware, llamada Conti. La campaña y el ataque que investigamos fueron interesantes porque marcaron el regreso de Ryuk con algunas modificaciones menores, pero también mostraron una evolución de las herramientas utilizadas para comprometer las redes objetivo y desplegar el ransomware.
El ataque también fue notable por la rapidez con que los ataques pueden pasar del compromiso inicial al despliegue del ransomware. A las tres horas y media de que un objetivo abriera un archivo adjunto de correo electrónico de phishing, los atacantes ya estaban realizando un reconocimiento de la red. En un día, habían obtenido acceso a un controlador de dominio, y estaban en las primeras etapas de un intento de desplegar el ransomware.
Los atacantes también fueron persistentes. Como los intentos de lanzar el ataque fracasaron, los actores de Ryuk intentaron varias veces durante la semana siguiente instalar nuevo malware y ransomware, incluyendo nuevos intentos de phishing para restablecer su posición. Antes de que el ataque hubiera concluido, más de 90 servidores y otros sistemas estaban implicados en el ataque, aunque el ransomware fue bloqueado para que no se ejecutara en su totalidad.
Deja entrar al equivocado
El ataque comenzó en la tarde del martes. 22 de septiembre. Varios empleados de la empresa objeto del ataque habían recibido correos electrónicos de phishing muy selectivos:
De: Alex Collins
To:
Asunto: Re: about debit
Por favor, llámeme hasta las 2 PM, estaré en la oficina hasta las 2 PM.
, debido a la solicitud de la oficina central #96-9/23 , procesaré 3,582 adicionales de su cuenta de nómina.
, llámeme cuando esté disponible para confirmar que todo está correcto.
Aquí tiene una copia de su declaración en PDF.
Alex Collins
especialista en subcontratación
El enlace, servido a través del servicio de entrega de correo Sendgrid, redirigía a un documento malicioso alojado en docs.google.com. El correo electrónico fue etiquetado con advertencias de remitente externo por el software de correo de la empresa. Y se detectaron y bloquearon varias instancias del archivo adjunto malicioso.
Pero un empleado hizo clic en el enlace del correo electrónico esa tarde. El usuario abrió el documento y habilitó su contenido, permitiendo que el documento ejecutara print_document.exe, un ejecutable malicioso identificado como Buer Loader. Buer Loader es un descargador modular de malware como servicio, presentado en foros clandestinos para su venta en agosto de 2019. Proporciona un servicio de distribución de malware gestionado por el panel web; cada compilación del descargador se vende por 350 dólares, con módulos adicionales y cambios de destino de la dirección de descarga facturados por separado.
En este caso, al ejecutarse, el malware Buer Loader dejó caer qoipozincyusury.exe, una «baliza» de Cobalt Strike, junto con otros archivos de malware. La baliza de Cobalt Strike, diseñada originalmente para la emulación de atacantes y las pruebas de penetración, es una herramienta de ataque modular que puede realizar una amplia gama de tareas, proporcionando acceso a las características del sistema operativo y estableciendo un canal de mando y control encubierto dentro de la red comprometida.
Durante la siguiente hora y media, se detectaron balizas adicionales de Cobalt Strike en el sistema inicialmente comprometido. Los atacantes pudieron entonces establecer con éxito un punto de apoyo en la estación de trabajo objetivo para el reconocimiento y la búsqueda de credenciales.
Unas horas más tarde, comenzó el reconocimiento de la red por parte de los actores de Ryuk. Los siguientes comandos se ejecutaron en el sistema inicialmente infectado:
- C:\WINDOWS\system32\cmd.exe /C whoami /groups (accede a la lista de grupos de AD en los que está el usuario local)
- C:\WINDOWS\system32\cmd.exe /C nltest /domain_trusts /all_trusts (devuelve una lista de todos los dominios de confianza)
- C:\WINDOWS\system32\cmd.exe /C net group «enterprise admins» /domain (devuelve una lista de los miembros del grupo «enterprise admins» del dominio)
- C:\WINDOWS\system32\net1 group «domain admins» /domain (lo mismo, pero una lista del grupo «domain admins»)
- C:\WINDOWS\system32\cmd.exe /C net localgroup administrators (devuelve una lista de administradores para la máquina local)
- C:\WINDOWS\system32\cmd.exe /C ipconfig (devuelve la configuración de red)
- C:\WINDOWS\system32\cmd.exe /C nltest /dclist: (devuelve los nombres de los controladores de dominio para el nombre de dominio de la empresa)
- C:\WINDOWS\system32\cmd.exe /C nltest /dclist: (lo mismo, pero comprobando los controladores de dominio que utilizan el nombre de la empresa como nombre de dominio)
Forward lateral
Usando estos datos, el miércoles por la mañana los actores habían obtenido credenciales administrativas y se habían conectado a un controlador de dominio, donde realizaron un volcado de datos de los detalles de Active Directory. Lo más probable es que esto se lograra mediante el uso de SharpHound, una herramienta de «inyección» de datos basada en Microsoft C# para BloodHound (una herramienta de análisis de Active Directory de código abierto utilizada para identificar rutas de ataque en entornos AD). Un volcado de datos de la herramienta se escribió en un directorio de usuario para la cuenta de administrador de dominio comprometida en el propio servidor de dominio.
Otro ejecutable de Cobalt Strike fue cargado y lanzado unas horas más tarde. Esto fue seguido inmediatamente por la instalación de un servicio Cobalt Strike en el controlador de dominio utilizando las credenciales de administrador de dominio obtenidas anteriormente. El servicio era un oyente encadenado de Server Message Block, que permitía pasar comandos de Cobalt Strike al servidor y a otros ordenadores de la red. Utilizando Windows Management Interface, los atacantes ejecutaron remotamente una nueva baliza Cobalt Strike en el mismo servidor.
En poco tiempo, se crearon otros servicios maliciosos en otros dos servidores utilizando las mismas credenciales de administrador, usando Windows Management Instrumentation desde el PC inicialmente comprometido. Uno de los servicios configurados era un comando PowerShell codificado que creaba otra tubería de comunicaciones Cobalt.
Los actores continuaron realizando actividades de reconocimiento desde el escritorio inicialmente infectado, ejecutando comandos que intentaban identificar objetivos potenciales para un mayor movimiento lateral. Muchos de ellos repetían comandos anteriores. El comando nltest se utilizó en un intento de recuperar datos de los controladores de dominio en otros dominios dentro del árbol de Active Directory de la empresa. Otros comandos hicieron ping a servidores específicos, intentando obtener direcciones IP. Los actores también comprobaron todos los recursos compartidos de red conectados a la estación de trabajo y utilizaron WMI para comprobar si había sesiones de Escritorio Remoto activas en otro controlador de dominio dentro del árbol de Active Directory.
Colocación de la trampa
A última hora de la tarde del miércoles -menos de un día después de que la víctima hiciera clic en el phishing- los actores de Ryuk comenzaron los preparativos para lanzar su ransomware. Utilizando la cabeza de playa en el PC inicialmente comprometido, los atacantes utilizaron RDP para conectarse al controlador de dominio con las credenciales de administrador obtenidas el día anterior. Una carpeta llamada C:\Perflogs\grub.info.test2 – Copy fue lanzada en el controlador de dominio – un nombre consistente con un conjunto de herramientas desplegadas en ataques anteriores de Ryuk. Unas horas más tarde, los atacantes ejecutaron un comando PowerShell codificado que, accediendo a los datos de Active Directory, generó un archivo de volcado llamado ALLWindows.csv, que contenía datos de inicio de sesión, del controlador de dominio y del sistema operativo de los equipos Windows de la red.
A continuación, se desplegó el proxy malicioso SystemBC en el controlador de dominio. SystemBC es un proxy SOCKS5 utilizado para ocultar el tráfico de malware que comparte código y marcadores forenses con otro malware de la familia Trickbot. El malware se instaló a sí mismo (como itvs.exe) y creó una tarea programada para el malware, utilizando el antiguo formato del programador de tareas de Windows en un archivo llamado itvs.job, con el fin de mantener la persistencia.
A continuación se ejecutó un script de PowerShell cargado en la carpeta grub.info.test del controlador de dominio. Esta secuencia de comandos, Get.DataInfo.ps1 , explora la red y proporciona una salida de los sistemas que están activos. También comprueba qué AV se está ejecutando en el sistema.
Los actores de Ryuk utilizaron varios métodos para intentar propagar archivos a servidores adicionales, incluidos los recursos compartidos de archivos, WMI y la transferencia de portapapeles del protocolo de escritorio remoto. WMI se utilizó para intentar ejecutar GetDataInfo.ps1 contra otro servidor.
Fallo de lanzamiento
El jueves por la mañana, los atacantes propagaron y lanzaron Ryuk. Esta versión de Ryuk no tenía cambios sustanciales con respecto a las versiones anteriores que hemos visto en cuanto a la funcionalidad principal, pero los desarrolladores de Ryuk añadieron más ofuscación al código para evadir las detecciones del malware basadas en la memoria.
El servidor de copia de seguridad de la organización fue uno de los primeros objetivos. Cuando Ryuk fue detectado y detenido en el servidor de copias de seguridad, los atacantes utilizaron el comando icacls para modificar el control de acceso, dándoles el control total de todas las carpetas del sistema en el servidor.
A continuación, desplegaron GMER, una herramienta de «detección de rootkits»:
GMER es utilizada con frecuencia por los actores del ransomware para encontrar y cerrar procesos ocultos, y para cerrar el software antivirus que protege el servidor. Los atacantes de Ryuk hicieron esto, y luego lo volvieron a intentar. El ransomware Ryuk fue redistribuido y relanzado tres veces más en poco tiempo, intentando superar las defensas restantes en el servidor de copia de seguridad.
Se dejaron caer notas de rescate en las carpetas que albergaban el ransomware, pero no se cifró ningún archivo.
En total, Ryuk fue ejecutado en ataques lanzados desde más de 40 sistemas comprometidos, pero fue bloqueado repetidamente por Sophos Intercept X. Al mediodía del jueves, la parte de ransomware del ataque había sido frustrada. Pero los atacantes no habían terminado de intentarlo y aún no habían salido de la red.
El viernes, los defensores desplegaron un bloqueo en los dominios afectados por el ataque para la RAT SystemBC. Al día siguiente, los atacantes intentaron activar otro proxy SOCKS en el controlador de dominio aún comprometido. Y se detectaron otros despliegues de Ryuk durante la semana siguiente, junto con otros intentos de phishing y de despliegue de Cobalt Strike.
Lecciones aprendidas
Las tácticas exhibidas por los actores de Ryuk en este ataque demuestran un sólido cambio respecto al malware que había sido la base de la mayoría de los ataques Ryuk del año pasado (Emotet y Trickbot). La banda de Ryuk cambió de un proveedor de malware como servicio (Emotet) a otro (Buer Loader), y aparentemente ha reemplazado a Trickbot con herramientas de explotación más prácticas en el teclado -Cobalt Strike, Bloodhound y GMER, entre ellas- y herramientas administrativas y de scripting de Windows incorporadas para moverse lateralmente dentro de la red. Y los atacantes cambian rápidamente de táctica a medida que surgen oportunidades para explotar la infraestructura de la red local: en otro ataque reciente al que respondió Sophos este mes, los actores de Ryuk también utilizaron objetos de política global de Windows desplegados desde el controlador de dominio para propagar el ransomware. Y otros ataques recientes han utilizado otra puerta trasera conectada a Trickbot conocida como Bazar.
La variedad de herramientas que se están utilizando, incluidas las herramientas de ataque de código abierto y las disponibles en el mercado, y el volumen y la velocidad de los ataques son indicativos de una evolución en las habilidades operativas de la banda Ryuk. La suite de «seguridad ofensiva» de Cobalt Strike es una de las herramientas favoritas tanto de los actores estatales como de los criminales, por su relativa facilidad de uso y su amplia funcionalidad, así como por su amplia disponibilidad: en los foros clandestinos se compran fácilmente versiones «crackeadas» del software con licencia comercial. Además, el software proporciona a los actores un kit de herramientas listo para la explotación, el movimiento lateral y muchas de las otras tareas necesarias para robar datos, escalar el compromiso y lanzar ataques de ransomware sin requerir un malware hecho a medida.
Aunque este ataque se produjo rápidamente, la persistencia de los ataques tras el fracaso inicial de Ryuk en el cifrado de datos demuestra que los actores de Ryuk -como muchos atacantes de ransomware- tardan en desencajar sus mandíbulas, y pueden persistir durante largos períodos de tiempo una vez que se han movido lateralmente dentro de la red y pueden establecer puertas traseras adicionales. El ataque también demuestra que el Protocolo de Escritorio Remoto puede ser peligroso incluso cuando está dentro del cortafuegos.