No cON Name 2022: Noviembre espera

Juan Antonio y yo siempre hemos tenido un gran cariño por este evento. En el año 2011 (un poco de historia, sniff sniff) acudíamos allí para presentar una charla. No fue una charla cualquiera, ya que digamos que era la primera vez que estábamos en un congreso de seguridad siendo ponentes. Y allí estábamos en Barcelona, hace 11 años, con cara de niños (algo la podemos mantener) y con ganas de darlo todo. 

En años posteriores, tuvimos talleres formativos en No cON Name, hacking, forense, pasamos algunos años impartiendo talleres... Es un congreso que llevamos con nosotros por todo lo que nos aportó en aquella época. Hoy, gracias a la organización de No cON Name, podemos comentaros lo siguiente:

• La cuenta de @fluproject (Twitter) dispone de descuentos para el "Reduced Pass". 
• Si quieres conseguir un código descuento, escribe a @fluproject en Twitter por DM y te lo daremos. 

Y a los que tengáis la oportunidad de participar en el evento, bien sea como público o como ponentes, disfrutad mucho de esta CON, que es legendaria y longeva, y que esperamos que todos podamos seguir  disfrutando por muchos años más.

Forensic Analysis of Windows Ransomware Attacks by Team Viewer with DeepBlueCLI

Hello everyone! In the last months I have the feeling that I just keep talking about cases and oddities related to the forensic analysis that we execute https://www.zerolynx.com/at Zerolynx, but unfortunately cyberattacks do not stop increasing, so we have to be prepared and updated regarding the modus operandi of cybercrime.

For about three or four years now we have had many practically identical cases related to ransomware. Victims and environments vary, ransomwares used vary, and attacker kits vary, but at its core, the attack chain is usually maintained, and the most common input vector we're seeing is still Team Viewer. Sometimes criminals manage to delete the logs, in other cases they stay halfway, in others, they do not even try, but in one way or another we always end up finding evidence that proves that Team Viewer has been the most possible way of entry. Therefore, today I wanted to dedicate this post to show you how to easily identify such behaviour in an attacked device, and what would be some of the first evidence that we could collect.

To illustrate the attack drill, I've prepared 2 Windows 11 test environments on VirtualBox, and installed Team Viewer on both. Default Settings. I give internet access to the machines and... let's go!

Now, and assuming that the attacker has obtained the ID and login credential (this topic can be addressed in another post), I authenticate:

And at this point I've done some “evil” things from the attacking machine, simulating the behaviour of a criminal.

At this stage, our forensics would begin, and we will assume that we have followed the correct procedure, adhering to the proper chain of custody, cloning the disk bit by bit (for example, with dd), and that we have processed it with some forensic tool like Autopsy. In the archive of Flu Project, you will find multiple posts where I talk about it at length :). And by the way, you have Forensic articles since 2011. In fact, the other day, while looking for a command, I came across with a compilation of 43 posts I made in 2013. But you have 50 more articles with newer techniques, tools and procedures.

Returning to our subject today, for this case I will use a SANS tool, DeepBlueCLI, which Pablo showed me a long time ago, and of which he already told you about in El Lado del Mal.

It is very easy to use: first you extract the Windows event logs, and then you introduce them as a parameter:

• .\DeepBlue.ps1 .\Forensics\eventsExtracted\security.evtx

You can do it on the logs of your Windows system without introducing any parameters:

As you can see, DeepBlue shows us that someone has recently created a user named "attacker” and has given this user administrator permissions. We take this data and go to the Windows event viewer to look for a "4720" event. And....here we are! we will easily find that someone has created the aforementioned user:

If we review the above events, we should find at some point the logon, event "4624":

As you can see, authentication occurs at 19:28 P.M. Now, if we refer to the Team Viewer event log, we will see that there was indeed a session that began at that time (the time is not well synchronized and you will see a gap of 2 hours), and that ended 3 minutes later:

In this type of attacks, it is common to find ID 4672 (special privileges assigned to the new login). Here is the detail of the Microsoft FAQ:

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

You may also find some traces related to the blockinb by the antivirus. You can see this with 7031 or 7000, that is, with the IDs that indicate that a service has been blocked and it has been prevented from starting:

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

We come up with this situation very frequently and clients always rise their eyebrows and go like: BUT I DID HAVE ANTIVIRUS! ARE YOUR KIDDING?! Well, sweetheart, if the attacker managed to become an administrator... your antivirus can't stop it. So there is nothing much that can be done than to avoid using users with privileged permissions.

And finally, and to conclude with the post, you may also find it useful to look for 11707 identifier which reflects that an application has been installed on the attacked machine. In all likelihood, a port scan or similar will have been executed. You can find it by the end of the table presented on the following Microsoft page:

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

Kino's blog may also be useful for this type of cases, since from time to time he dedicates post to topics related to the audit of Windows events. For example, this one where he explains how to monitor changes in the log may be useful. It is likely probable that the attacker uses a kit executed from powershell, and has to modify something in the log, such as execution directives.

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

This article provides you with some basic concepts to quickly investigate an incident of this kind. There are better attackers who delete logs and make things more difficult for us, and others who are blinded by success and leave more traces than they would like, but one way or another we always end up getting the information we need to prove the attack. Identifying the attacker is another story... IP addresses from China is what we're finding more recently, but I'm sure this doesn't come as a surprise to you :).

See you on the next post!

Autor: Juan Antonio Calles

Microsoft MVP de Azure

My Public Inbox

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