Análisis forense de ataques ransomware en Windows por Team Viewer con DeepBlueCLI

Buenas a todos, en los últimos meses no hago más que hablaros de casos y de curiosidades relacionadas con los análisis forenses que vivimos desde Zerolynx, pero por desgracia los ciberataques no dejan de incrementarse, por lo que nos toca estar preparados y actualizados en lo referente al modus operandi de la ciberdelincuencia.

Desde hace unos tres o cuatro años nos llegan muchos casos prácticamente idénticos relacionados con el ransomware. Varían las víctimas y los entornos, varían los ransomwares utilizados, y varían los kits de los atacantes, pero en esencia, la cadena de ataque suele mantenerse, y el vector de entrada más común que estamos viendo sigue siendo Team Viewer. En ocasiones el delincuente logra borrar los logs, en otras se queda a medias, en otras, ni lo intenta, pero de una manera o de otra siempre acabamos localizando un artefacto que nos evidencia que Team Viewer ha sido la más que posible vía de entrada. Por ello, hoy he querido dedicar este post para enseñaros como podríamos identificar un comportamiento de este tipo en un equipo atacado de forma sencilla, y cuales serían algunas de las primeras trazas que podríamos recolectar.

Para ilustrar el simulacro de ataque he montado 2 entornos de prueba Windows 11 sobre VirtualBox, y he instalado Team Viewer en ambos. Instalación por defecto. He dado conectividad a internet a las máquinas y a funcionar:

A continuación, y asumiendo que el atacante ha obtenido el ID y la credencial de acceso (esto da para otro post), me he autenticado:

Y en este punto he realizado algunas cosas "malas" desde la máquina atacante, simulando el comportamiento de un delincuente.

En esta fase comenzaría nuestro forense, y vamos a asumir que hemos seguido el procedimiento correcto, levantando la debida cadena de custodia, clonando el disco bit a bit (por ejemplo, con dd), y que lo hemos procesado con alguna herramienta forense tipo Autopsy. En el historial de Flu Project os aburriréis de posts donde hablo de ello largo y tendido :). Y, por cierto, tenéis artículos de Forense desde 2011, de hecho, el otro día me encontré mientras buscaba un comando con un recopilatorio de 43 posts que hice en 2013. Pero tenéis otros 50 artículos más con técnicas, herramientas y procedimientos más actuales.

Volviendo al hilo, para este caso utilizaré una herramienta de SANS, DeepBlueCLI, que me enseñó Pablo hace tiempo, y de la que ya os habló en El Lado del Mal.

Su uso es muy sencillo, en primer lugar extraeríais los logs de eventos de Windows, y a continuación, se los pasaríais como un parámetro:

• .\DeepBlue.ps1 .\Forense\eventosExtraidos\security.evtx

A modo de práctica, podéis hacerlo sobre los propios logs de vuestro sistema Windows sin pasarle ningún parámetro:

Como veis, DeepBlue nos muestra que alguien ha creado recientemente un usuario llamado "atacante", y le ha dado permisos de administración. Por lo que con este dato vamos a irnos al visor de eventos de Windows a buscar un evento "4720". Y premio, fácilmente encontraremos que alguien ha creado el citado usuario:

Si revisamos los eventos anteriores, deberíamos encontrar en algún punto la autenticación a la máquina, evento "4624":

Como vemos, la autenticación se produce a las 19:28 P.M. Ahora, si nos vamos al log de eventos de Team Viewer, veremos que efectivamente hubo una sesión que comenzó a esa hora (la hora no está bien sincronizada y veréis un gap de 2 horas), y que finalizó 3 minutos después:

En este tipo de ataques será habitual encontraros con el ID 4672 (privilegios especiales asignados al nuevo inicio de sesión), os dejo con el detalle de la FAQ de Microsoft:

• https://docs.microsoft.com/es-es/windows/security/threat-protection/auditing/event-4672

También es posible que os encontréis con algunas trazas relativas a la parada del antivirus de la máquina, esto lo podréis ver con el 7031 o el 7000, es decir, con los IDs que indican que se ha parado y no ha podido arrancar un servicio:

• https://docs.microsoft.com/es-ES/troubleshoot/windows-client/system-management-components/windows-trace-session-manager-service-not-start-event-id-7000

Esto nos lo encontramos muchísimo y siempre tras ello llega la misma pregunta del cliente. ¡PERO SI TENÍA ANTIVIRUS! ¡VAYA MIERDA! Bueno hijo, por mucho antivirus que tengas, si el atacante logró llegar a ser administrador... lo puede parar. Así que poco se puede hacer más que evitar el uso de usuarios con permisos privilegiados.

Y, finalmente, y por concluir con el post, también puede resultaros útil buscar el identificador 11707, que refleja que se ha instalado una aplicación en la máquina atacada. Con toda probabilidad, se habrá montado algún escáner de puertos o similar. Podréis verlo hacia el final de la tabla presentada en la siguiente página de Microsoft:

• https://docs.microsoft.com/es-es/windows/win32/msi/event-logging

El blog de Kino puede seros de utilidad también para este tipo de casos, dado que de vez en cuando dedica algún post a temas relativos a la auditoría de eventos de Windows. Por ejemplo, este donde explica como monitorizar los cambios en el registro puede veniros bien. Es muy posible que el atacante use algún kit que lance desde powershell, y tenga que tocar algo en el registro, como las directivas de ejecución.

• http://kinomakino.blogspot.com/2020/01/auditar-cambios-en-el-registro-sin.html

Con lo que os he contado en este artículo tenéis unas nociones básicas para investigar rápidamente un incidente de este tipo. Hay atacantes mejores que borran logs y nos ponen las cosas más difíciles, y otros que se ciegan por el éxito y dejan más huellas de las que les gustaría, pero por H o por B siempre acabamos obteniendo la información que necesitamos para acreditar el ataque. Ya lo de identificar al atacante es otro cantar... Últimamente lo que más nos encontramos son direcciones IPs de China, pero no creo que os sorprenda :).

¡Hasta el próximo post!

Autor: Juan Antonio Calles

Microsoft MVP de Azure

My Public Inbox