Los profesionales de seguridad constantemente revisan informes de amenazas, artículos y blogs sobre diversas técnicas defensivas y ofensivas. Estos incluyen descripciones detalladas de intrusiones reales.
Aquí, queremos continuar con esta tendencia, pero con un pequeño giro.
En lugar de presentar una línea de tiempo ordenada de los eventos (aunque también lo haremos), abordaremos este caso particular desde el punto de vista del analista que realizó la investigación.
Cada intrusión es diferente, y también lo son los caminos de investigación que las desentrañan.
¡Acompáñanos mientras recorremos uno de estos caminos!
Todo comienza
Aunque podamos pensar que las intrusiones son lineales, con el ataque avanzando ordenadamente del paso uno al paso dos y así sucesivamente, rara vez es así como la intrusión se revela desde el punto de vista de un analista.
Con frecuencia, un analista recibe una señal o una alerta de una intrusión que ya está en curso.
Por ejemplo, un analista puede recibir una alerta sobre movimiento lateral. En este caso, podemos asumir que también estuvieron presentes algún tipo de acceso inicial y posiblemente técnicas de extracción de credenciales, ya que suelen ser requisitos necesarios para el movimiento lateral.
Esta dinámica se puede ilustrar con la siguiente imagen:
En este caso particular, el analista recibió varias señales, todas agrupadas en el mismo período. Estas señales contenían evidencia de:
- La adición de un usuario local al endpoint afectado
- La incorporación del usuario recién creado a los grupos de administradores locales y de usuarios de escritorio remoto
- La modificación del registro del endpoint afectado para facilitar un mayor movimiento lateral mediante el protocolo de escritorio remoto (RDP)
- La modificación del registro del endpoint afectado para omitir el Control de cuentas de usuario (UAC)
En este punto, el analista cuenta con algunas piezas clave de información:
- El actor de amenazas de alguna manera está dentro de la red; aún no se conoce el método de acceso inicial.
- El actor de amenazas tiene credenciales administrativas en el endpoint afectado, ya que son necesarias para agregar cuentas de usuario y modificar el registro.
- El actor de amenazas parece querer moverse lateralmente por la red.
- El actor de amenazas ha establecido un medio de persistencia mediante la cuenta de usuario recién creada.
Durante las investigaciones, se da una dinámica a menudo paradójica.
Más información a veces no genera mayor claridad, sino solo más preguntas.
Podemos saber que el actor de amenazas está dentro de la red, e incluso conocer los métodos de movimiento lateral, pero aún faltan piezas clave de la intrusión.
Para seguir desentrañando este caso, debemos continuar con nuestro proceso de investigación.
Tirando de un hilo
Un hilo del que podemos tirar son las relaciones entre procesos principales y secundarios dentro de la telemetría de procesos disponible para el analista.
Aunque existen muchas formas de crear un usuario en un equipo con Windows y agregar ese usuario a un grupo en particular, si estas acciones las realizara de manera normal un administrador de sistemas, el linaje de procesos se vería algo así:
Explorer.exegenera un símbolo del sistema o una ventana de PowerShell- El símbolo del sistema o PowerShell genera
net.exeonet1.exe net.exeonet1.exetiene una línea de comandos similar a esta:net localgroup Administrators <user> /add
Además, si un administrador de sistemas estuviera modificando legítimamente las configuraciones de RDP, esperaríamos que estos eventos provinieran de algún tipo de proceso de gestión de sistemas.
Si el administrador de sistemas realizó estas acciones mediante la línea de comandos, esperaríamos ver un linaje de procesos similar al ejemplo de net localgroup que mostramos arriba.
En este caso, un examen de las relaciones entre procesos principales y secundarios arrojó resultados interesantes:
Los comandos de manipulación del registro descritos anteriormente se generaron a partir del proceso wsmprovhost. Esto indica que el actor de amenazas se estaba moviendo lateralmente dentro del entorno usando el protocolo WinRM.
Esta información es interesante por varias razones. Primero, nos da un punto de referencia. Sabemos que este actor de amenazas en particular se mueve lateralmente por la red usando WinRM, entre otros métodos, así que tiene sentido revisar cualquier otro proceso generado a partir de wsmprovhost.exe dentro del entorno.
Segundo, esta información nos indica que el actor de amenazas probablemente se movió lateralmente hacia el endpoint afectado desde algún otro lugar, así que debemos seguir esta pista para encontrar el origen del movimiento lateral.
Por último, esta información nos dice que el actor de amenazas tiene credenciales que le dan acceso a varios equipos de la red.
Esta es una dinámica desafortunada que encontramos con frecuencia. Una vez que un actor de amenazas está dentro de la red, por lo general no hay muchos controles para evitar el movimiento lateral. En la mayoría de los casos, las cuentas administrativas, en particular las cuentas de administrador local, tienen permisos sobre la mayoría —si no todos— los recursos de la red, incluidos recursos sensibles como controladores de dominio, servidores de archivos y servidores de aplicaciones.
Con esta información en mente, seguimos examinando las relaciones entre procesos principales y secundarios. Este examen dio resultados. Mientras seguíamos esta pista de investigación, descubrimos que los procesos principales de toda la actividad de manipulación de usuarios descrita anteriormente se generaron a partir del sospechoso proceso Veeam.Backup.MountService.exe:
¡Muy interesante y, de hecho, algo preocupante! ¿Por qué se generan estos comandos desde el servicio de Veeam Backup? ¿Cómo obtuvo el actor de amenazas acceso a este sistema o aplicación?
Con esta nueva información en mano, se investigó más a fondo el sistema afectado para ver si existía una versión vulnerable de Veeam Backup & Replication. Efectivamente, descubrimos que el servicio instalado estaba desactualizado y le faltaban parches.
El equipo de Huntress ya ha escrito antes en detalle sobre esta vulnerabilidad, y todos sabemos que aplicar parches es difícil, así que no sorprende encontrar software antiguo por ahí.
Tras investigar más a fondo el sistema, se encontró un artefacto de script de PowerShell a través del canal de registro operativo de PowerShell, evento ID 4104:
Este script se usó para extraer credenciales del servicio vulnerable de Veeam, y al parecer estas credenciales se usaron para lograr ejecución de código a través del servicio vulnerable.
Con este conocimiento en mano, ahora tenemos una comprensión más profunda de la intrusión, pero todavía no sabemos cómo el actor de amenazas:
- Obtuvo un punto de apoyo persistente en el entorno en primer lugar (acceso inicial)
- ¿Cómo se localizó la instancia vulnerable de Veeam? (Descubrimiento)
Para responder estas preguntas, debemos cambiar un poco el enfoque: de observar la telemetría de procesos a observar los registros de eventos de Windows.
Vamos a los registros de eventos
Debido a la cantidad de actividad maliciosa que Huntress observa, tenemos un punto de vista único y podemos extrapolar indicadores de compromiso a partir de las diversas intrusiones que encontramos.
Uno de esos indicadores son los nombres de estaciones de trabajo. Ciertos nombres de estaciones de trabajo se observan en varias intrusiones, y en este caso en particular, uno de esos nombres maliciosos conocidos apareció en nuestro radar.
Esta estación de trabajo maliciosa atacó a un puñado de cuentas de usuario con un ataque de fuerza bruta que duró alrededor de dos minutos antes de, lamentablemente, lograr acceso a una de las cuentas en la red. Esta actividad ocurrió desde una dirección IP interna, lo que sugiere que estuvo casi adyacente al vector de acceso inicial, pero no fue el vector de acceso inicial en sí.
La intrusión ahora se ve con un poco más de claridad.
Ahora sabemos que:
- Un actor de amenazas entró en el entorno y realizó un ataque de fuerza bruta.
- Este ataque de fuerza bruta tuvo éxito y provocó el compromiso de credenciales.
- Estas credenciales se usaron para obtener acceso a un sistema en el entorno.
- En este sistema, se explotó un servicio de Veeam para robar más credenciales.
- La actividad posterior en este sistema incluyó la creación de una cuenta de usuario además de la modificación del registro para facilitar más movimiento lateral.
Sin embargo, quedan algunas preguntas. Todavía no sabemos cómo el actor de amenazas entró al entorno en primer lugar, y tampoco sabemos cómo se descubrió el servicio de Veeam. ¿Este servicio fue atacado específicamente o se detectó de manera oportunista?
Al investigar a partir del nombre de la estación de trabajo maliciosa, encontramos algunos eventos de autenticación interesantes que contienen un usuario objetivo de “ANONYMOUS LOGON”; la brillante investigadora de seguridad Lina Lau tiene un blog fantástico sobre lo que significan estos eventos de autenticación. Aunque se registran como una autenticación exitosa, eso no siempre es necesariamente el caso.
Una mejor forma de pensar en estos eventos es más en línea con un intento de autenticación exitosa. Sin embargo, el hecho de que la autenticación falle no significa que no arroje información investigativa interesante.
Cuando examinamos los eventos de autenticación que contenían este tipo de eventos “ANONYMOUS LOGON”, descubrimos otro nombre de máquina interesante que contenía el nombre de la popular herramienta de escaneo nmap.
Ahora tenemos otra pieza del rompecabezas, y algunas respuestas potenciales sobre cómo se descubrió el servicio de Veeam en primer lugar. La palabra “potencial” aquí es sumamente importante, ya que a menudo los datos disponibles están incompletos, fragmentados o simplemente faltan.
En este caso, la evidencia es, en el mejor de los casos, circunstancial, ya que lo único que tenemos es el nombre de la máquina, el cual puede cambiarse fácilmente. Además, incluso si estos eventos sí ocurrieron a partir de una ejecución de nmap, no sabemos si el escaneo en sí apuntó específicamente a Veeam.
Sentirse cómodo con los vacíos y las incógnitas es una parte fundamental de lidiar con este tipo de intrusiones. Aunque todos desearíamos que cada sistema estuviera equipado con todas las herramientas relacionadas con telemetría, como Sysmon y captura de paquetes completa, lamentablemente este no es el caso en el mundo real.
En este punto, solo queda una pieza del rompecabezas: el vector de acceso inicial.
Descubriendo el acceso inicial
En nuestro blog anterior sobre acceso inicial, destacamos un dispositivo VPN de cara externa como un vector de acceso inicial extremadamente popular. Este caso no es diferente, y se sospecha fuertemente que el compromiso de la VPN fue el vector de acceso inicial.
A partir de la dirección IP asociada con la actividad de movimiento lateral, el equipo de Respuesta Táctica de Huntress revisó la telemetría de VPN proporcionada y encontró un evento de autenticación sospechoso. Sin embargo, como el dispositivo VPN no retiene mucha telemetría, solo pudimos identificar un evento de cierre de sesión y no uno de inicio de sesión:
Al igual que con la ejecución de nmap mencionada anteriormente, la evidencia de esto también es circunstancial e incompleta. Esta dinámica ilustra un elemento muy común, aunque poco mencionado, del análisis de intrusiones y la respuesta a incidentes: lidiar con telemetría poco clara o faltante. En este caso, podemos suponer que el dispositivo VPN fue el vector de acceso inicial, pero lamentablemente carecemos de evidencia definitiva de esto.
Ahora que el panorama completo de la intrusión es mucho más claro, mapeado con el marco de MITRE ATT&CK y presentado en orden operativo, nuestra intrusión se verá más o menos como se muestra a continuación:
Para cerrar
Esperamos que hayas disfrutado este análisis de una de las investigaciones que manejó el Centro de Operaciones de Seguridad de Huntress (SOC) y el equipo de Respuesta Táctica.
En cuanto a la investigación, buscamos resaltar la metodología siempre que fue posible. Una cosa es decir de forma genérica "monitorea los intentos de fuerza bruta" o "está atento a relaciones anómalas entre procesos padre e hijo", y otra muy distinta es poner en práctica e implementar dichas técnicas de investigación. Esperamos que esta mirada interna a nuestro enfoque haya ayudado a afianzar y aclarar estos conceptos.
Mapeo de MITRE ATT&CK
| Táctica | ID de técnica | Nombre de técnica | Descripción |
|---|---|---|---|
| Acceso inicial | T1133 | Compromiso de VPN | Compromiso del dispositivo VPN |
| Reconocimiento | T1595 | Escaneo activo | Uso de nmap |
| Acceso a credenciales | T1110 | Fuerza bruta | Ataque de fuerza bruta contra cuentas existentes |
| Movimiento lateral | T1021.006 | Servicios remotos: Windows Remote Management | Movimiento lateral mediante WinRM |
| Ejecución | T1203 | Explotación para ejecución en cliente | Explotación del servicio Veeam |
| Persistencia | T1098 | Manipulación de cuentas | Agregar usuario al grupo de usuarios de escritorio remoto |
| Evasión de defensas | T1112 | Modificar el registro | Habilitar más movimiento lateral mediante RDP |
Reglas Sigma aplicables
¡Un agradecimiento especial a todos los autores de reglas Sigma y colaboradores de la comunidad!
- Registro de ransomware Blackbyte
- Posible manipulación de claves de registro relacionadas con RDP mediante Reg.EXE
- Proceso secundario sospechoso de la base de datos de Veeam
- Ejecución de script de extracción de credenciales en servidores de respaldo de Veeam
- Actividad sospechosa de reconocimiento de grupos y cuentas mediante Net.EXE
- Procesos sospechosos generados por WinRM
