Ransomware ate my network (IV)

[Nota del editor: Pinchando en muchas imágenes –aquellas cuyo detalle no se ve del todo con el tamaño de la página principal– se muestra una versión ampliada]

En el artículo anterior vimos cómo Ángela había deducido que los atacantes habían entrado en el equipo empleado para conectarse al DC desde otro equipo empleando la herramienta PsExec. Dispuesta a encontrar el PsExec, Ángela empieza convirtiendo a .csv la MFT extraída por CyLR con mftdump.exe, y buscando por actividad alrededor de la la hora en la que vio la conexión en el otro equipo (sobre las 14:16h, 13:16h en UTC que es lo que nos muestra la MFT).

No hay un objetivo claro, pero ese Prefetch de stalin.exe parece sospechoso (recordemos que los Prefetch se crean la primera vez que se ejecuta el software, con un retraso de unos pocos segundos).

Si buscamos ese stalin.exe en los logs de Sysmon, nos encontramos que, aunque PsExec se ponga bigote y beba vodka, no puede engañarlo:

Aquí podemos ver cómo se lanza el launcher.bat en W10-PC3 que ejecuta el stager de Empire. Hay varios detalles adicionales que son muy interesantes:

• El padre de ese PsExec es dosdivanya_security.bat (script a revisar con cariño)
• Se ha ejecutado como SYSTEM (es decir, dispone de privilegios de sistema)
• La contraseña de la cuenta admin (administrador local) es (suspiro) … Fiesta2020
• Tanto PsExec como dosdivanya_security.bat están en la carpeta de Documentos del usuario dolores.jolgorio

Si revisamos los logs de Sysmon, comprobamos que el padre de  dosdivanya_security.bat es … un script de Powershell codificado. Está claro que los atacantes se han montado un “imperio” de agentes de Empire en los equipos del MINAF.  Ángela decide revisar el contenido de la carpeta Documentos de dolores.jolgorio, y encuentra que los atacantes se han dejado un arsenal de herramientas:

Podemos encontrar ya a viejos conocidos (launcher.bat, plink.exe, launch_plink.bat, stalin.exe),. Adfind.exe es una herramienta de reconocimiento de Directorio Activo (que forma parte de las TTP de Ryuk), y gonchaya.exe tiene un icono que Ángela reconoce de inmediato como el de BloodHound (otra herramienta de reconocimiento de Directorio Activo muy empleada en seguridad ofensiva).

Aunque quedan varios ficheros por analizar (dosdivanya_security nyetAV.reg y stolichnaya_def.exe), el tener todos estos ficheros aquí induce a Ángela a pensar que este equipo es la cabeza de puente de la intrusión. Vamos a ver el contenido de los mismos:

Parece bastante claro el objetivo: montar el C: del equipo destino (algo que tampoco debería de estar permitido), copiar el stager de Empire y luego ejecutar PsExec para lanzarlo de forma remota.

NyetAV.reg tampoco tiene mucha complicación: su objetivo es desactivar Windows Defender desde el registro. El último fichero, sin embargo, parece mucho más misterioso: VirusTotal lo detecta como malicioso, pero no hay un veredicto sólido que nos permita definir para qué sirve este ejecutable. Ángela decide lanzarlo en una sandbox de forma manual, y obtiene este resultado:

… junto con un terminal con privilegios de administrador. Está claro que el ejecutable es un exploit de elevación de privilegios, al parecer relacionado con BITS. Un poco de OSINT permite determinar que el exploit usado es el CVE-2020-0787, posiblemente gracias a una de las PoC ya disponibles en Github. Lo peor de todo es que esa vulnerabilidad fue parcheada en MARZO DE 2020.  La guillotina ya no parece ser suficiente, habrá que prender fuego a todo el edificio de la FFP…

Dispuesta a desmenuzar metódicamente todas las acciones de los atacantes, Ángela coge los logs de Sysmon y se dispone a desgranar todas las actividades de los atacantes. Sysmon permite, con cuidado, ir “rebobinando” todo lo que han hecho en el sistema. En último lugar (recordad que vamos hacia atrás en el tiempo) se puede observar la ejecución de SharpHound (el módulo de ingesta de datos de BloodHound):

La herramienta se ha ejecutado correctamente, porque podemos ver que el directorio Documentos aparece el fichero de resultados 20201109133730_BloodHound.zip (que nos indica incluso el momento en el que se ejecutó). Ángela recupera el fichero y se lo pasa a Salvador para que lo importe en su VM de auditoria, que tiene BloodHound instalado, y el resultado está claro:

BloodHound es una herramienta muy, muy potente. Una de sus funcionalidades es la de detectar dónde han iniciado sesión los administradores de dominio. Con estos resultados en la mano, queda claro porqué los atacantes se movieron lateralmente a W10-PC5: ahí es donde sabían gracias a BloodHound que podían encontrar las credenciales de un administrador de dominio.

Justo antes de SharpHound los atacantes lanzan un script llamado adfin.bat, que contiene varias llamadas a adfind.exe con diversos parámetros y cuyo objetivo es obtener información sobre el dominio (usuarios, grupos, controladores de dominio, etc.)

Unos momentos antes podemos ver (por partida doble) cómo el antivirus es defenestrado por la carga de nyetAV.reg:

El ser metódicos tiene su recompensa: casi nos olvidamos de la persistencia, en este caso fácilmente detectable por Sysmon al tener correctamente cargados los EventID 19,20 y 21 (relativos a WMI):

Lo más interesante ocurre a las 13:01h cuando Sysmon ve cómo el exploit del CVE-2020-0787 se despliega en todo su esplendor lanzado desde un agente de Empire:

Muy interesante el “extra” de crear un usuario administrador local, y sobre todo el hecho de que el launcher11.sct (otro de los stagers de Empire, que en este caso se lanza con privilegios de administrador local realizando la EoP) se ha lanzado desde 101.132.122.215, lo que constituye un nuevo IOC que guardamos cuidadosamente.

Si seguimos rebobinando hacia atrás (Sí, Ángela ha usado un VHS. Y sí, también se tiñe las canas) Ángela encuentra una cosa muy interesante:

Aquí podemos ver cómo los atacantes están lanzando el stager de Empire … pero lo que lo está lanzando NO parece estar relacionado con Empire ¿Qué puede estar pasando aquí? Ángela sabe que hay grupos de ciberdelincuentes que se especializan en conseguir accesos, vendiéndolos luego a otros grupos como Ryuk que son los que se encargan de realizar la intrusión y desplegar el ransomware. Se anota investigar ese rundll32.exe para saber de dónde puede haber salido.

[Nota del autor: En efecto la idea era que pasara un cierto tiempo entre el primer y el segundo acceso, para así simular el tiempo en el que el primer grupo “pone a la venta” el acceso y el segundo grupo lo adquiere. Problemas logísticos (cometí un error con la recuperación de un snapshot que no sincronizó bien tiempos y descuadró todo el escenario) me obligaron a realizar de nuevo el escenario … sin ese margen temporal que tan bonito había quedado]

Poco antes del despliegue del agente de Empire, se observan una ristra bastante estándar de comandos de reconocimiento:

Es un poco curioso, porque parte de esa información ya la tenían los atacantes gracias a Adfind y BloodHound. Esto refuerza la teoría de Ángela de dos grupos de atacantes (los primeros reconociendo el terreno y los segundos confirmando que el acceso es “legítimo”).

Ángela se queda con la duda de cómo los atacantes han podido hacerse con la contraseña del admin local de la FFP. Está claro que “Fiesta2020” no es una contraseña especialmente robusta (probablemente ni 5 minutos de hashcat con un buen conjunto de diccionarios y reglas), pero… de algún sitio la han tenido que sacar, ¿no? (recordemos que Windows 10 no tiene Wdigest, por lo que no hay contraseñas en claro).

Aplicando un poco de pensamiento deductivo, y con la teoría de los dos grupos, el grupo que ha lanzado el exploit (y por ello conseguido privilegios administrativos) es el segundo, el que hace uso de Empire. Si revisamos las opciones de Empire comprobamos que tiene un comando llamado powerdump que sirve para volcar los hashes de las contraseñas locales. Podemos entonces estudiar el código fuente de powerdump, identificar cadenas de código únicas y buscarlas en el volcado de memoria de W10-PC5.

Al final la lógica apunta a que los atacantes han hecho uso de Powerdump, pero la lógica y las evidencias son como la caña y la tapa: juntas están mucho mejor:

A estas alturas de la investigación parece que solo queda encontrar el vector de entrada. Sysmon no tiene sentimientos, y si seguimos mirando hacia atrás encontramos una tragedia en varios actos:

Primer acto: El misterioso rundll32.exe lanzando un cmd.exe y confirmando la intrusión en el equipo.

Segundo acto: la conexión contra el C2 (ojo, nuevo IOC: 101.132.122.214) de rundll32.exe.

Tercer acto: El padre de rundll32.exe no es Darth Vader … pero como si lo fuera ¿De verdad, usuarios de la FFP? ¿No habéis hecho cursos de concienciación? Ángela busca en el disco duro el fichero, pero aunque en su interior ya sabe lo que va a encontrar necesita verlo con sus propios ojos:

Una cosa está clara: los grandes clásicos nunca mueren. Ahora Ángela solo necesita dos cosas: qué hay dentro de ese documento, y cómo ha llegado al MINAF. VirusTotal lo detecta como malicioso, pero no nos deja nada claro qué puede ser:

Ángela extrae la macro maliciosa, que tampoco parece por sí sola dar muchas pistas:

Pero un poco de búsqueda en fuentes abiertas nos deja un estupendo artículo de nuestros compañeros de Tarlogic, que señala esa macro como perteneciente a Metasploit (otra conocida suite de explotacion/post-explotación):

[Nota del autor: En un escenario real, la macro maliciosa descargaría Emotet, que podría a su vez descargar Trickbot o KegTap. Como no tenemos a mano un C2 de Emotet se ha optado por Metasploit para simular esa primera intrusión].

Para saber cómo ha entrado, revisamos el historial de navegación del usuario, y encontramos fácilmente la descarga (repetidas veces, cuidado) del fichero en los registros de navegación de la usuaria dolores.jolgorio (recordad que en las reglas de la simulación ignorábamos en las evidencias todo lo que pasara antes del 9 de noviembre, así que no le hagáis caso a esos launcher.bat, son atrezzo):

No habiendo rastros de navegación, todo apunta a que el vector de entrada real es el correo electrónico. En este caso los equipos de la FFP no tienen Outlook sino que emplean la propia app de  Mail de Windows 10 (posturetas), pero a Ángela le cuesta bien poco encontrar el correo malicioso:

La app de Mail de Windows es definitivamente MUY POCO forensic friendly. Toda la información de los correos se guarda en C:Users[User]AppDataLocalComms, pero los metadatos se guardan en el fichero store.vol, una base de datos ESE (Extensible Storage Engine), que podemos abrir con EseDatabaseViewer y tiene este aspecto:

Al final Ángela termina guardando el correo como .eml y abriéndolo en un editor de textos, con resultados más bien parcos en lo relativo a metadatos:

Por lo menos obtiene lo necesario para rastrear el correo en los logs de la pasarela: un Real From (admin@mina.es) y un asunto (Reorganizacion FFP).  Con estos datos comprueba que el correo fue enviado el 4 de noviembre a otras 11 personas de la FFP, y que por suerte, dolores.jolgorio ha sido la única en picar en el spear-phishing.

Si ahora volvemos a ver la película en la dirección correcta, queda claro lo que hicieron los atacantes:

1. Envían con un correo con macro maliciosa, y consiguen que una usuaria lo abra.
2. Despliegan un agente de Meterpreter.
3. Reconocen el sistema.
4. Hacen el cambio de Meterpreter a Empire.
5. Elevan privilegios con el exploit de la vulnerabilidad CVE-2020-0787.
6. Vuelcan credenciales locales con Powerdump.
7. Reconocen el dominio e identifican W10-PC3.
8. Lanzan un agente de Empire vía PsExec.

Con todos los aspectos del incidente ya analizados, ya solo quedan las fases de erradicación, recuperación y las lecciones aprendidas … que veremos en el último artículo de la saga.

La entrada Ransomware ate my network (IV) aparece primero en Security Art Work.