DR. RYUK

Un bonito día de mayo mientras parte de los integrantes del DET (DFIR ECC Team) estaban dando clase en la universidad, un hospital español sufre un incidente de seguridad. El centro hospitalario se pone en contacto con los integrantes del DET, y tras una primera reunión telefónica, nos envían una serie de evidencias que claramente apuntan a que se trata de un ataque por ransomware, más exactamente un Ryuk: un tipo de ransomware descubierto en agosto de 2018, que está capacitado para encriptar unidades de red y también shadow copies en el endpoint que está siendo atacado.

En la reunión, los miembros del equipo técnico del hospital trasladaron que tuvieron que desconectarse completamente de internet, por lo que no pueden gestionar absolutamente nada. Por ello, comenzamos a trabajar en conjunto y contrarreloj para devolver al centro a la normalidad. El primer paso, fue trazar una estrategia común.

Esta primera fase la realizamos de forma remota desde nuestros laboratorios en Madrid. La estrategia comienza, además de analizando las notas de rescate que nos permitiera determinar que se trataba de un Ryuk, analizando el tráfico de red desde el día 5 de mayo, fecha en la que se nos llama, hasta el día 1 del mismo mes. Gracias a los Excel, se pudo ver que existían conexiones recurrentes a un dominio extraño desde varios equipos. Este dominio se trataba de “silenceel.com”.

Tras buscar junto a nuestro equipo de Threat Intelligence, descubrimos que se relacionaba con un C2 de Cobalt Strike por lo que, como es habitual, había más piezas de malware ocultas asociadas a la ejecución del ransomware. Estas llamadas al dominio se produjeron el día 3 de mayo, dos días antes de que el equipo empezara a trabajar de forma rápida y sincronizada en el operativo de intervención.

Una vez obtenida la URL del dominio malicioso, se identificaron todas las direcciones IP locales que realizaron algún tipo de petición hacia este, y se vio que había más de 50 equipos afectados. Una vez identificado, se pidió a los encargados de los EDR de una conocida marca de seguridad informática que aplicasen la política de bloqueo contra el dominio y la dirección IP de éste. Con esto empezamos a cerrar la primera puerta a los malos. A continuación, lanzamos en varios equipos al azar de esos 50: dos aplicativos, el primero Loki, un simple scanner de IoCs (Indicators of Compromise, y Windows Live Response, un programa que permite recoger artefactos de Windows para posteriormente analizarlos. En dos de ellos, detectamos la ejecución de un script de Mimikatz y un volcado del registro de la SAM.

La clave de registro SAM permite saber cuáles son los usuarios que hay en ese equipo, a partir de ahí, los ciberdelincuentes pueden empezar a campar a sus anchas y Mimikatz, es un arsenal de herramientas creado por Benjamin Delphy con la finalidad de atacar una vulnerabilidad de los protocolos de Windows que permite robar credenciales de los usuarios y así luego estos acceder de forma legítima.

Este arsenal de herramientas usa técnicas como:

• Pass-the-Ticket: los datos de contraseña de un usuario en Windows se guardan en los llamados Tickets Kerberos. Mimikatz ofrece al hacker la posibilidad de acceder a este ticket y autenticarse sin necesidad de utilizar una contraseña.
• Kerberos Golden Ticket: este es un ataque tipo Pass the Ticket. Este ticket corresponde a una cuenta oculta llamada KRBTGT; que no es otra que la cuenta que encripta todos los demás tickets. Este ataque ofrece un pase dorado al hacker; para que pueda obtener derechos de administrador de dominio que no caducan.
• Kerberos Silver Ticket: en este caso, Kerberos otorga un ticket TGS a un usuario y este puede utilizarlo para conectarse a cualquier servicio de la red.
• Pass-the-Cache: también podría entrar en la clasificación de ataques tipo Pass the Ticket. La única diferencia es que en este caso; Mimikatz utiliza los datos de conexión grabados y cifrados de un sistema Mac/UNIX/Linux.
• Pass-the-Hash: no importa si el atacante no tiene acceso a la contraseña en texto plano, del dispositivo al que quiere saber. Con Mimikatz, el hacker puede usar los hashes NTLM para autenticarse y acceder al sistema. 

Viendo el panorama tan desalentador, y dado que el tiempo apremiaba, el equipo decidió coger todo el arsenal de herramientas forenses y presentarse en el hospital para trabajar  junto al cliente y, de esta forma transmitirle, algo importante en estas situaciones: tranquilidad Unas horas después de tomar la decisión, ya estábamos en el punto exacto donde el jefe de informática del hospital nos había indicado, con  todas nuestras herramientas  desplegadas y reunidos con el gabinete de crisis que se había formado. En esta reunión, se trazó un plan para contener el ataque, se pidió un mapa de la arquitectura de red para entenderla, y se hizo la pregunta más incómoda en estas situaciones: ¿se tienen backups en lugares seguros de fechas recientes? -en este caso, sí-. Además, se preguntó si también han sido cifrados al encontrarse en la misma red. Visto esto, el asunto se pone más crítico ya que la recuperación no va a ser tan ágil como esperábamos, y recordemos que esto es un hospital que está parado.

Comienza la caza y la búsqueda del paciente 0

Gracias a la información obtenida de los perimetrales tenemos una idea de quién es, pero como en todas las situaciones de un IR el escenario no era el ideal. Direcciones IP dinámicas y sin posibilidad de recuperar asignaciones de estas con carácter retroactivo. Por ello decidimos empezar por los equipos que sustentaban los servicios más críticos para el hospital en ese momento.

Mi equipo y yo, acompañados por el jefe de informática del hospital, nos dirigimos a Urgencias y encendemos los equipos de las salas de Rayos y Ecos, Windows XP y Windows 7, etc. Sacamos nuestros USB y volvemos a ejecutar en todos ellos: Loki y WLR y, lo mismo, Mimikatz y SAM. Otros equipos, los desmontamos y sacamos sus discos duros para ingestarlos en Axiom y en FTK Imager, dos herramientas clave en un IR que nos van a ayudar a sacar ficheros protegidos por el sistema, logs del sistema, la MFT, el Journal del sistema, así como otra serie de artefactos que van a ser claves para la investigación… Había mucho trabajo por delante.

A la mañana siguiente, empezamos a buscar el beacon(un componente de malware que permite conectividad empleando protocolos como HTTP, HTTPs o DNS) de Cobalt Strike entre los equipos que se habían conectado al famoso dominio que se encontró al principio.

Dicho componente, se encontraba en las VDI de Citrix y se había identificado con uno de los usuarios de la organización y bingo, tenemos al paciente 0. Rastreando desde dónde se habían conectado, dimos con una dirección de Kaliningrado (Rusia), También por sorpresa, con el mismo usuario, encontramos una dirección de Estados Unidos de AWS con el puerto 3389 abierto (RDP). Tirando del hilo, vimos que estas conexiones se establecieron el 1 de mayo. Vamos viendo la luz en medio del caos.

Seguimos analizando equipos y gracias a los eventos de Windows comprobamos que el siguiente paso que dan, es conectarse vía RDP desde la VDI al controlador de dominio, también con el mismo usuario que han usado anteriormente. Teniendo esto en cuenta esto, preguntamos al jefe de informática dónde estaba y empezamos a rebuscar por los logs del sistema, para entender que es lo que han hecho los hackers: han ejecutado con éxito un Golden Ticket (un token de autenticación Kerberos), empleando para ello un usuario llamado MOVIL-1$.

Y así, descubrimos que, el 2 de mayo, un elemento que tiene cierto parecido a otro de Windows llamado svchost. Analizándolo vemos que se trata de una dll que dentro tiene escondidos varios regalos: el primero, que vuelve a hacer referencia a nuestro dominio silenceel; y el otro, una variable llamada Melón. Analizándola con nuestros editores hexadecimales, nuestros PEstudios y ResourceHackers, vemos que esta dll, se acaba convirtiendo en un bonito loro.

Seguimos revisando esa máquina para descubrir con nuestra herramienta FullEventLogViewer, que se han creado varios servicios con nombres aleatorios de 7 letras, parece un patrón de Cobalt Strike versión 4.1.

Nos encontramos más novedades: descubrimos algunos IOCs relacionados con ZeroLogon CVE 2020-1472, vulnerabilidad en la criptografía del proceso Netlogon que permite al atacante suplantar cualquier ordenador, incluido el controlador de dominio raíz. Analizándolo con detenimiento, vemos que los hackers no han conseguido explotar dicha vulnerabilidad. Este fallo fue tan simple como que trataban de explotar el administrator en un equipo en español, por lo que se denomina administrador.

Analizado ya, casi todo el controlador de dominio, seguimos cerrando puertas y viendo cada paso que han dado. Lo siguiente es el uso de una herramienta llamada ADFind, que permite obtener información muy jugosa del directorio activo, los usuarios y los grupos establecidos. Gracias a esta herramienta, se observa que con otro de los usuarios legítimos crean procesos ilegítimos los cuales nos llevan al ejecutable del Ryuk y que son ejecutados por el administrador del equipo del que ha sido vulnerado el usuario legítimo.

Este ejecutable es el encargado de encriptar todos los ficheros de los sistemas y lo encontramos con tres nomenclaturas diferentes.

Mientras estamos trabajando, el gerente del hospital, viendo como trabajamos de forma rápida y minuciosa, no para de agradecernos lo que estamos haciendo. Durante este tiempo de asueto y de desconexión, nos comenta que de los 37 bitcoins que pedían en la nota de rescate, están dispuestos a pagar en bitcoins medio millón de euros… ¡Jamás se debe acceder a tal chantaje! Pagar las notas de rescate se considera delito en España y te convierte en objetivo de campañas mucho más agresivas. Menos mal que no se ha pagado nada.

Continuamos analizando el Controlador de Dominio y vemos hay algún que otro cambio en las GPO a nivel de dominio. Los hackers se están poniendo las botas, pero nosotros tenemos la última palabra y estamos seguros de han cometido más fallos. Así, otro de los hallazgos, fue la ejecución de icacls que se usa para abrir permisos en las carpetas de la unidad C (para no tener que usar usuario y contraseña) y, siguiendo con ello, vemos cómo se crean las notas de rescate. Esto nos resultó muy curioso puesto que se descubren una serie de ficheros de tipo dll ubicados en la ruta C:\Users\Public\. Analizando su código, vemos que son CSS y que se forman de 5 caracteres alfanuméricos. Además, observamos en los eventos del sistema la creación de varias tareas programadas que llaman al WordPad y a las dll anteriormente identificadas para generar las notas de rescate.

Hemos acabado ya con el Controlador de Dominio, pero nos falta otra cosa más, ¿dónde se ha producido la exfiltración de los datos? necesitamos saber qué información se han llevado urgentemente. Empezamos a revisar varios equipos y servidores. Ya en nuestra última máquina identificada y que teníamos que analizar, empezamos a revisar todos los ficheros y detectamos un fichero de tipo dll de más de 6 GB… Y, al cambiar la extensión de .dll a .rar encontramos los documentos que nuestros amigos se querían llevar: historiales oncológicos, historias médicas, nóminas, etc.

Seguimos investigando y vemos que se han descargado WinSCP y también identificamos la dirección IP a donde querían mandar estos datos, una en Reino Unido de un VPS. Analizando los logs, nos dimos cuenta de un último hallazgo: ¡No han sido capaces de extraer la información! Cuando llevaban 1.5 GB (de un total de 6 GB) el equipo de IT del hospital cortó la conexión hacia internet, esto les estropeó el intento de exfiltración.

Y ya por fin, cerramos todas las puertas a nuestros amigos realizando una serie de acciones que se describen más abajo. Nunca había sentado tan bien volver a escuchar el atronador sonido de las sirenas.

Como dirían nuestro nuevo grupo de “amigos”: Ура!!, Мы выиграли!!!

Oportunidades de detección y bloqueo de este TTP

Oportunidad de detención y bloqueo 1

Ø  Gestión de contraseñas

• Valorar incluir la herramienta KeePass
• Habilitar el protocolo NTLM versión 2
• Mantener el cambio de contraseña.

Oportunidad de detención y bloqueo 2

Ø  Robustecer la gestión de usuarios desde el punto de vista operativo, de cara a que estos empleen los permisos estrictamente necesarios para sus labores.

Ø  Robustecer la gestión de accesos a los recursos disponibles, con el objetivo de evitar en la medida de lo posible accesos a información que no sea necesaria para el desempeño de las funciones laborales.

Ø  Robustecer los accesos desde el exterior de la organización, mediante, por ejemplo, el uso de un doble factor de autenticación.

Oportunidad de detención y bloqueo 3

Ø  Deshabilitar la conexión del protocolo RDP entre máquinas dentro de la organización

Oportunidad de detención y bloqueo 4

Ø  Cambiar o habilitar en el servicio de gestión de correo un sistema que permita realizar investigaciones, retenciones y análisis de la información vertida en este.

Oportunidad de detención y bloqueo 5

Ø  Gestión de ejecutables. Valorar incluir herramientas para el bloqueo de archivos ejecutables, a fin de que no puedan llevarse a cabo ejecuciones de aplicaciones que no hayan sido permitidas por parte de la organización.

Oportunidad de detención y bloqueo 6

Ø  Monitorización de infraestructura

Oportunidad de detención y bloqueo 7

Ø  Bastionado de PowerShell

• Prevenir la conexión de Powershell a Internet
• Restringir la ejecución de Powershell.
• Bloquear o limitar que usuarios u ordenadores pueden ejecutar de forma remota Powershell a través de WS-Management (WSMan/WinRM).
• Limitar el uso de Powershell a version 4.0 o mayor. Si es posible limitar la ejecución a la version 5.0 o mayor.
• Deshabilitar la capacidad de hacer downgrade de Powershell.
• Restringir el modo "Constrained language" al nivel de grupos de política en máquinas Windows (GPO) (Las GPO están localizadas en Computer Configuration\Preferences\Windows Settings\Environment).
• Permitir solo la ejecución de scripts firmados de Powershell (Las GPO están localizadas en Computer Configuration\Policies\Administrative Templates\Windows Components\Windows PowerShell).
• Desinstalar versiones de powershell antiguas y no usadas.
• Forzar el login de powershell a nivel de dominio.

Oportunidad de detención y bloqueo 8

Ø  Detallar el carácter de la información almacenada que se considere crítica o sensible, a fin de poder realizar una correcta división de esta y por lo tanto poder realizar las respectivas restricciones.

Ø  Bastionar los activos en los que se almacene información de carácter sensible, entendiendo como tal una acción conjunta de monitorización del sistema, restricción de accesos, actualización periódica y control de acciones realizadas en los mismos, así como llevar a cabo la protección del contenido sensible alojado en el mismo.

Ø  Alojar copias de seguridad semanales realizadas fuera de la organización y protegidas por contraseña.

Autor del artículo

Diego Cordero, Delivery manager de Risk Advisory de Deloitte