Ransomware ate my network (III)

En el artículo anterior la investigación se había quedado con el equipo con la IP 10.11.2.14 como origen de las conexiones al DC (y que tenía tanto conexiones con el C2 101.143.122.216 como el antivirus desactivado de forma previa al ataque generalizado).

Dado que estamos hablando de conexiones y que disponemos de la memoria RAM, lo primero que hace Ángela es emplear el plugin netscan de Volatility para sacar las conexiones de red (el perfil de memoria es Win10x64_17134) y confirmar las conexiones con el C2:

Netscan devuelve a su vez unos cuantos resultados adicionales:

¿Una conexión a un SSH remoto?

¿Y qué hace este equipo prestando un servicio en el puerto 443/TCP? ¿Se ha vuelto loco? Está claro que tenemos que profundizar en estas conexiones saber qué hay detrás de ellas. Ángela decide revisar los logs de Sysmon, en los que tendrían que aparecer las conexiones de red… pero parece que la FFP no aplicó correctamente la configuración de Sysmon estándar del MINAF, por lo que no se están recogiendo esos datos (grrrrrrr).

Sin embargo sí que se recogen las creaciones de procesos (EventID 1), por lo que tras un poco de rebuscar puede encontrar el proceso que realiza la conexión SSH:

plink.exe es un compañero de putty.exe (el cliente ligero de SSH de Windows por excelencia), y se emplea para realizar conexiones SSH de forma automatizada.

Lo que se está lanzando con ese comando es básicamente un túnel entre el equipo del atacante y el equipo local, de forma que todo el tráfico que pase por el puerto 12345/tcp del equipo del atacante se redirija al puerto 443/tcp de este equipo (que es la otra conexión extraña que habíamos visto).

Dos detalles importantes: el padre de este equipo es launch_plink.bat, lo que implica que podemos tener otros procesos implicados … y que plink se está ejecutando como admin, el usuario administrador local de la FFP que Ángela comprueba que parece seguir activo (en lugar de haber sido eliminado con la integración con el servicio de contraseña única vía LAPS del MINAF).  Queda pendiente una charla pendiente con los informáticos de la FFP. Con herramientas cortantes.

Al seguir revisando los eventos de Sysmon Ángela encuentra el otro comando de launch_plink.bat, y entiende el propósito del puerto 443:

El comando netsh se emplea en Windows para la manipulación de la configuración de red, y en este caso lo que especifica es una redirección de puertos desde el puerto local 443/tcp al puerto 3389/tcp   (el controlador de dominio del MINAF). En resumidas cuentas, los dos comandos conforman un elegante pivot SSH-RDP, que permite a los atacantes entrar por Escritorio Remoto al DC desde su equipo atacante).

Si seguimos buscando, encontramos el lanzamiento del script launch_plink.bat:

Más código Powershell ofuscado. Los atacantes probablemente no hayan sido muy imaginativos, por lo que Ángela busca más ejecuciones de launcher.bat … y el que busca, encuentra:

Este log nos da una información muy importante: el stager de Empire se ha lanzado vía PsExec, una de las herramientas por excelencia de movimiento lateral, y como administrador local.

El ver este evento le dice a Ángela dos cosas: en primer lugar, que tenemos al menos otro equipo más comprometido en la red. Y en segundo lugar, que muy probablemente sea de la FFP, porque a estas alturas está prácticamente segura de que la contraseña de administrador local es la misma en todos los puestos de usuario.

Dado que PsExec emplea SMB, Ángela puede recuperar el netscan e investigar las conexiones al 445/tcp:

Aparecen dos equipos, pero uno de ellos (10.11.2.16, también de la FFP) es el tercer equipo que sufrió una “defunción prematura” del antivirus, así que Ángela ya sabe por dónde continuar su investigación.

Una duda le asalta: si los atacantes ya tenían control de otro equipo, ¿por qué atacaron este? ¿Qué tiene este equipo de especial para constituir un objetivo? Ángela imagina la respuesta, pero necesita datos para confirmar su hipótesis así que saca del log de eventos de Seguridad un listado de todos los usuarios que han iniciado sesión en el equipo (EventID 4624), lo exporta a texto y lo hace un grep por los nombres de cuenta:

maria.feliz y dolores.jolgorio son personal administrativo de la FFP, admin es el administrador local  del equipo … y dom.adm es el administrador de dominio que habíamos visto que emplearon los atacantes para conectarse al DC. Ángela está segura de que, si pregunta por ese inicio de sesión a los administradores de sistemas de la FFP le responderán “es que siempre hemos administrado los equipos así, es lo más fácil”. La reunión va a tener que hacer con guillotina incluida…

Sabiendo que aquí tenemos un administrador de dominio, es más que posible que los atacantes se hayan conectado para realizar un volcado de credenciales. Por lo que conoce de las TTP de Ryuk, suelen usar LaZagne o Mimikatz, así que Ángela puede emplear el plugin strings de Volatility para ver si encuentra cadenas características de alguno de esos dos programas.

Después de 15 minutos de espera de Volatility (no sabe por qué, pero a veces se queda enganchado), Ángela piensa: “en realidad no necesito el plugin de Volatility porque no necesito saber qué proceso está lanzando la herramienta, solo si se ha lanzado o no, y eso lo puedo sacar de las strings base«.

Parando la herramienta busca cadenas de ambos programas … y encuentra el temido “kiwi de la muerte” de Mimikatz:

Al menos los equipos son Windows 10, y al tener Wdigest deshabilitado por defecto evitan que la contraseña salga en claro. Buscando con cuidado, encuentra la parte relativa a la cuenta dom.adm:

Tampoco aparece la contraseña … ¿cómo pueden entonces haberse conectado por RDP al DC si solo tenían el hash NTLM? Ángela lo consulta con Salvador, que responde al vuelo: !PtH! !PtH! Al parecer, es posible realizar un ataque de Pash-the-Hash contra el protocolo RDP … pero solo si está la característica de seguridad “Restricted Admin” habilitada en el equipo destino (que sirve para que las credenciales no se queden almacenadas en el equipo, y de esa forma proteger ante posibles volcados).  Eso explica esa autenticación NTLM que Ángela vió en el DC …

Cabreada como una mona porque los atacantes hayan aprovechado una medida de seguridad en su contra, Ángela decide no dejar piedra sin remover. Ya sabe de dónde vienen los atacantes, a dónde han ido y lo que han hecho. Tan solo le falta comprobar si han dejado “regalitos” en el equipo en forma de persistencia.

Hay muchas formas de comprobar la persistencia, pero Ángela decide emplear las armas de los atacantes en su contra: ya que están empleando herramientas libres (Empire) … su código fuente está disponible, por lo que puede descargar el Powershell encargado de gestionar la persistencia y estudiarlo:

https://github.com/EmpireProject/Empire/blob/master/data/module_source/persistence/Persistence.psm1

La función principal dice lo siguiente:

New-ElevatedPersistenceOption allows for the configuration of elevated persistence options. The output of this function is a required parameter of Add-Persistence. Available persistence options in order of stealth are the following: permanent WMI subscription, scheduled task, and registry.

Dado que tenían privilegios de administrador, y que WMI es la persistencia más sigilosa, vamos a probar suerte. El código fuente indica que ésta es la orden real que establece la persistencia:

$ElevatedTrigger = "`"```$Filter=Set-WmiInstance -Class __EventFilter -Namespace ```"rootsubscription```" -Arguments
@{name='Updater';EventNameSpace='rootCimV2';QueryLanguage=```"WQL```";

Por lo que podemos buscarla en las cadenas de la memoria y … !bingo!

No queda duda alguna de que este equipo debe ser pasto del fuego purificador.  Tomando un momento para dar un paso atrás y ver el incidente de forma global, Ángela empieza a ver claro lo que está pasando: los atacantes han entrado en este equipo porque posiblemente sabían que tenía una sesión iniciada de administrador de dominio, han obtenido el hash NTLM, y han montado el pivot SSH-RDP para poder entrar en el DC.

Queda por ver qué nos depara el análisis del equipo 10.11.2.16 … que lo veremos en el siguiente artículo.

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