El día en que NoName no fue NoName

Diario de un Incident Responder es una serie de artículos en los que el equipo de Digital Forensic and Incident Response (DFIR) de Deloitte relata cómo realiza sus operativos cuando atiende incidentes de seguridad.

Estas entradas van a tener 3 partes diferenciadas: en la primera, se presentará un texto introductorio desde el punto de vista de un integrante del equipo de DFIR; en el segundo apartado, se desarrollará una muestra técnica del ataque; y en el tercero, se abordarán las posibles acciones para bloqueo o detección que sean aplicables en cada fase del ataque.

El equipo de DFIR de Deloitte aporta una experiencia de más de una década atendiendo incidentes de seguridad de toda clase y condición, y en los entornos más inverosímiles posibles.

El día en que NoName no fue NoName

Era domingo y, en casa, eso significa que toca comer arroz. Eran las 14 de la tarde cuando sonó el teléfono y al otro lado estaba mi responsable indicando que en una hora teníamos que estar en una ubicación para que nos recogieran. Conforme colgué, apuré mi plato de arroz con setas y magro y me dirigí a la ubicación indicada.

Normalmente, no sabemos dónde vamos hasta que no nos recogen o llegamos al punto de encuentro. Tampoco sabemos cuántos días nos vamos, salvo por una estimación que nos hacen al recibir esa llamada de activación de operativo por parte del responsable del equipo. Nuestro trabajo tiene una parte de sorpresa y de incertidumbre que resulta apasionante.

Una vez allí, nos recogieron a otro integrante del equipo de DFIR y a mí a la hora acordada. En el coche, nuestro responsable nos indicó que nos dirigíamos a la sede de una empresa que estaba sufriendo un ataque de Ransomware y, que por las notas de rescate y el tipo de archivo identificado con la terminación de archivo “.noname” seguramente estaríamos ante un ataque del grupo con el mismo nombre

NoName es un grupo ampliamente conocido y que basa sus actuaciones en realizar intrusiones en empresas para obtener información y venderla a terceros. Sus técnicas y tácticas son bastante conocidas, por lo que ya estábamos preparando todo nuestro arsenal de YARA, SIGMA, y HUNTS para iniciar el operativo de la forma más enfocada posible.

Llegamos a las oficinas del cliente y nuestra primera acción fue tener una reunión con el Comité de Crisis de la compañía, generado exprofeso para el incidente. La reunión se inició pidiendo al cliente que nos contara qué había ocurrido y qué acciones se habían llevado a cabo hasta ese momento. Con la información facilitada, iniciamos nuestra ronda de preguntas para poder dibujar un escenario. Estas preguntas abarcan desde quién ha identificado que ocurría algo fuera de lo habitual hasta cómo se ha producido la identificación, pasando por fechas, horas o cualquier tipo de dato que pueda ayudar en el operativo de respuesta.

El responsable de IT de la compañía nos comenta que, en esos momentos, tienen todos los servicios detenidos, ya que la acción para bloquear el cifrado de los equipos fue desconectar la red.

De esta reunión sacamos lo siguiente: una posible ventana temporal, un posible usuario fraudulento y un código malicioso, que es el que desplegaba el Ransomware, así como el código del propio script malicioso y el estado actual del incidente. Ya tenemos con qué empezar a trabajar.

La primera acción que realiza el equipo de DFIR es remitir la muestra del código malicioso a nuestro equipo de CTI, para que extraigan las capacidades de dicho código y, así, nosotros podamos entender qué podemos buscar o qué tipo de acciones podemos tratar de identificar.

Lo que nos reportan nos rompe todos los esquemas. Nos indican que no se corresponde con el modus operandi habitual del grupo NoName y que, con toda certeza, se trate de una suplantación de identidad entre grupos de ciberdelincuentes. Esto hace que replanteemos la estrategia ampliando el alcance y descartando la hipótesis inicial.

Con la información disponible sabíamos que dentro de la ventana temporal especificada deberían de haberse generado una serie de cambios o eventos, tanto en las máquinas como en el propio Controlador de Dominio de la organización.

Se me asigna la misión de revisar la actividad producida en el Controlador de Dominio de la organización para poder determinar maquinas afectadas o cambios no esperados que no hayan sido identificados. Lo primero que advierto es que no existen archivos cifrados. Esto es habitual en este tipo de ataques para que el atacante no pierda mucha de su capacidad operativa dentro de la empresa atacada.

Uso una herramienta de triaje para poder hacer un primer acercamiento, a la vez que reviso de forma manual registros, usuarios, grupos, etc…

A primera vista identifico que, efectivamente, se ha creado un usuario administrador del dominio dentro de las fechas indicadas y que no sigue el formato habitual de la compañía. Este usuario, además, trata de asemejarse a un servicio legítimo de un sistema de backups existente en la compañía.

Una vez identificado el usuario, mi siguiente movimiento es identificar quién ha creado dicho usuario, ya que esto me daría la pista del administrador vulnerado con anterioridad. Mientras hago estas revisiones, la herramienta de triaje ha terminado y ya puedo analizar los resultados. Este triaje recopila cosas como los EVTX del sistema o los logs de aplicaciones y usuarios.

Inicio la revisión de los logs de EVTX y lo primero que identifico es que existe un borrado de logs en la fecha indicada, junto a la ejecución del ransomware, por lo que asumo que el Controlador de Dominio ha sido manipulado con técnicas anti-forenses. Esto supone un problema a la hora de mi análisis, ya que no voy a tener toda la información disponible. Pensando como atajar esto, se me ocurre que puede haber una copia de seguridad del propio Controlador de Dominio que quizá conserve esos registros y muchos más.

Me pongo en contacto con el responsable de IT para trasladarle la duda.

Y… Tenemos suerte y existe una de justo antes de la hora marcada en el evento como borrado de logs.

Realizo de nuevo las operaciones de triaje pero, en esta ocasión, sobre la copia del DC en la que se supone que deben de estar los logs que buscamos y no tardo en identificar que, efectivamente, tenemos lo que necesitamos.

Con esta nueva copia soy capaz de identificar el administrador que ha creado el usuario malicioso en la organización y que, por supuesto, tiene privilegios en el dominio.

Lo traslado a mi responsable, quien de forma inmediata localiza el equipo del usuario en cuestión, lo asigna a mi compañero, que realiza un análisis en profundidad, sin poder identificar cómo se ha vulnerado dicho usuario, ya que no se ha realizado desde el equipo del afectado.

Por mi parte, sigo rascando en los logs del Controlador de Dominio e identifico la conexión del usuario administrador vulnerado. Para nuestra sorpresa, su dirección IP de origen es la de la VPN de la organización. Esto me indica que, probablemente, dichos movimientos se han realizado desde el exterior de la organización y que dicho usuario ya estaba vulnerado con anterioridad.

Debido a este hallazgo tan relevante dejo el análisis del Controlador de Dominio y traslado dicha información a mi responsable, quien me prioriza la revisión de los sistemas perimetrales de la organización para tratar de esclarecer la dirección IP de origen y, si es posible, más acciones llevadas a cabo desde dicha dirección IP.

Para ello, lo que hago es revisar las asignaciones de DHCP por parte del sistema de VPN, siendo este un FortiClient. Al ver la versión instalada y el tipo de petición generada, identifico que se trata de una versión con un fallo de seguridad muy relevante y que no se encuentra solventado. Este fallo de seguridad es el reportado como CVE-2018-13379, que se corresponde con que un atacante remoto no autenticado puede enviar una petición diseñada que contenga una ruta específica para leer archivos arbitrarios del dispositivo.

Entre estos archivos accesibles por cualquier usuario se encuentra el listado de USER/PASS que se han autenticado en la VPN, con lo que mi siguiente paso es identificar fugas de información asociadas al CVE. Localizo un leak que es público y en el que se encuentra, como sospechaba, el usuario administrador con el que los atacantes han iniciado sus operaciones.

¡Bien! ¡Tengo el vector de entrada!

Ahora me toca tirar para tras en el tiempo para ver el primer acceso de este usuario vulnerado. Sin embargo, las noticias no son buenas… Este usuario lleva más de un mes accediendo a la empresa desde una VPN de Alemania.

Comunico estos hechos y se modifica el plan de acción para centrar los esfuerzos en identificar los pasos que no conocemos desde la fecha del primer acceso. El proceso, para ello, pasa por revisar la dirección IP interna a la que accede con cada intrusión y determinar los posibles saltos y acciones que ha llevado a cabo. Con esto, se sabe que el tipo accede a una máquina que emplea como centro de operaciones y que se basa en un sistema operativo Windows XP. Este sistema se encuentra fuera de soporte desde hace mucho, pero es algo que hoy sigue existiendo en las organizaciones, ya que en muchas ocasiones hay elementos que únicamente funcionan con dichos sistemas.

Inmediatamente, me pongo a revisar la actividad de esta máquina, pero como buen Windows XP que es, no registra prácticamente nada. Sin embargo, consigo identificar que se ha ejecutado un Mimikatz para volcar las credenciales de forma recurrente, entendiendo que es para poder cazar a algún usuario que no se registre de forma externa o que le haga falta algún administrador en particular.

Durante las revisiones de los diferentes equipos hemos identificado, instalaciones de herramientas legítimas como AnyDesk o VNC llevadas a cabo por el usuario malicioso, borrado de eventos de forma masiva, uso de Remote Desktop para los movimientos laterales y el empleo de diferentes herramientas para mapear la red.

Ya tenemos varios elementos del ataque, el vector de entrada, cómo se ha movido por la red, las implementaciones que han ido realizando durante su intrusión y las posibles puertas traseras existentes. Vamos por buen camino.

Ahora nos toca saber cómo se ha distribuido el ransomware y cómo se ha ejecutado.

Volvemos con mi análisis del Controlador de Dominio y consigo identificar que el día del cifrado se ha creado una GPO (Política de grupo) en el dominio, que apunta a la ejecución de un script en PowerShell que se encuentra ubicado en SYSVOL (conjunto de archivos y carpetas que residen en el disco duro local de cada Controlador de Dominio de un Dominio) del propio Controlador de Dominio. Esta GPO indicaba a los equipos que, cuando un usuario se autenticase en el sistema, de forma automatizada se ejecutara el script malicioso, el cual cifraba los archivos con una terminación “.noname” y, por último, borraba los logs de eventos, dejando el equipo prácticamente limpio.

Con toda la información recopilada y todos los pasos del ataque entendidos, volvemos a casa y a nuestras oficinas para poder iniciar los trabajos de acompañamiento de forma remota para la reconstrucción de los servicios afectados por el ataque junto con la revisión e implementación de las recomendaciones de bastionado extraídas durante el operativo.

Todas estas acciones nos han llevado 4 días, trabajando unas 16 horas, comiendo lo justo y corriendo de un sitio a otro, pero no lo cambio por nada del mundo y lo volvería a hacer mañana mismo.

Oportunidades de detección y bloqueo de este TTP

Oportunidad de detención y bloqueo 1

• Actualizar FortiClient VPN a la última versión.

Oportunidad de detención y bloqueo 2

• Monitorizar peticiones anómalas o repetitivas desde direcciones IP en un corto espacio de tiempo.

Oportunidad de detención y bloqueo 3

• Deprecar los sistemas operativos sin soporte del fabricante como Windows XP.

Oportunidad de detención y bloqueo 4

• Bloquear accesos a Github, Pastebin u otras direcciones que permitan la descarga de malware.

• Asegurarse que los sistemas de AV están activos y actualizados.

• Monitorizar cambios en el Windows Defender para detectar posibles desactivaciones del mismo.

Oportunidad de detención y bloqueo 5

• Hacer uso de una política de contraseñas segura, para evitar que varios servicios tengan la misma contraseña y asegurar una rotación periódica de estas.

Oportunidad de detención y bloqueo 6

• Auditar la instalación de herramientas de tipo RAT como AnyDesk o VNC.

• Monitorizar los servicios instalados mediante el evento 7045 de Windows.

• Monitorizar los cambios en el firewall de los endpoints o servidores (El servicio AnyDesk abre puertos).

Oportunidad de detención y bloqueo 7

• Monitorizar la creación de usuarios mediante el evento 4720 de Windows.

• Monitorizar la inclusión de usuarios al grupo de administradores mediante el evento 4732 de Windows.

Oportunidad de detención y bloqueo 8

• Bastionar PowerShell, para evitar ejecuciones maliciosas de código en PowerShell.

• Aplicar sistema de log y transcripción para PowerShell.

Oportunidad de detención y bloqueo 9

• Monitorizar la creación de GPOs mediante el evento 5137 de Windows.