Memorias de un DFIRER Vol. VIII
![Memorias de un DFIRER Vol. VIII](https://d135r5feqs3c1t.cloudfront.net/2022/02/image_750x_620f87318fa67.jpg)
Tiempo de lectura estimado: 11 minutos
Esta conferencia magistral pertenece al Módulo 10 “Análisis forense. Malware y técnicas de ocultación” de C1b3rWall Academy 2021/2022. El objetivo de la misma es exponer algunos casos prácticos de ataques de ransomware.
Disclaimer: Los casos expuestos son verídicos pero se ha ocultado la identidad original de las víctimas. Tienen un fin puramente académico y se ha cambiado el nombre de los casos a películas famosas.
Caso Fast & Furious
Un día del confinamiento de marzo de 2020 un cliente le manda una foto de su escritorio con todos los archivos cifrados con extensión .devos, procedente del ransomware Phobos.
Me conecté por VPN a la empresa y por escritorio remoto al servidor donde están los ficheros. El servidor tenía una carga elevada y un proceso sospechoso en memoria (AntiR.exe). Se identifica en Downloads del usuario “prueba” y al tener mala pinta el cliente bloquea al usuario “prueba”. En el directorio las propias herramientas de la máquina estaban cifradas. Me descargo el .exe y subo el hash a virustotal y 65 de 72 lo detectan como malo.
Mientras estoy conectado sacando evidencias el cliente avisa de que se están cifrando ficheros de otros equipos. Con el usuario “prueba” fuera de combate miro su actividad en el pasado (NTUser.dat y eventos). Descubro que se han ejecutado los archivos que estaban en la máquina y los eventos se han borrado después del acceso (esto significa que “prueba” era administrador).
Según el cliente el sistema no estaba expuesto y esa máquina no estaba conectada a internet. No hay eventos pero el usuario era de dominio, por tanto, en el controlador de dominio se puede intentar identificar la actividad de este usuario. Solo tenía los eventos de hace 7 días, no por tiempo sino por tamaño, ya que los nuevos ocupaban más y habían sobreescrito a los antiguos.
Detectamos en el registro que el atacante hizo un ataque de fuerza bruta o diccionario y que después accedió a recursos locales compartidos. Ha tenido accesos válidos de red (tipo 3) a otros hosts en la red e identifico uno que es relay entrante de correo. Me intento conectar a ese pero me da errores de todo tipo. El cliente fue la primera que vio y la apagó.
Me envían el equipo a casa al día siguiente y le saco un disco. Intento acceder desde una máquina Linux forense al contenido del disco y no entiende el sistema de archivos. Arranco el equipo desde varios USBs forenses y ninguno es capaz de ver el disco. El cliente dijo que si arrancaba y al probar enciende con normalidad. Me da un usuario de administrador local de la máquina y conecto WinTriage (herramienta de libre uso) en un pendrive, me lo cifra.
Conecto otro con las herramientas cifradas y elimino de la memoria la ejecución del proceso malicioso. Extraigo los eventos y veo lo mismo que en la máquina del servidor de ficheros. Veo conexiones con autenticación satisfactoria de tipo 10 (a través de escritorio remoto), pero se conectan desde su propia IP privada hacia sí mismas. También hay una IP pública pero que se conecta a sí misma (una IP de la empresa). En el Userassist veo acciones previas a las anteriores. Como conclusión, se contuvo el incidente bastante rápido.
Caso No me chilles que no te veo
Un amigo me reenvía un cliente con ransomware de hace una semana. Se trata de una empresa del sector industrial con todo cifrado (hasta el NAS de backup) y con una copia fría bastante antigua.
Los ficheros eran .ryk, INCIBE le recomendó guardar los archivos por si publicaban en el futuro la clave maestra pero no les daba solución. El atacante pedía 20 BTC y el cliente decide no pagar.
Nos pidió que les ayudáramos a mejorar su seguridad para el futuro. Hablamos con el informático que iba un día a la semana, nos cuenta que tienen una red plana con un firewall Mikrotik. Apenas analizaba la navegación de los usuarios y los antivirus que tenían son demos gratuitas de muchas marcas. No tenía políticas del directorio activo y los usuarios podían instalar software como administradores locales de su máquina.
Le hacemos una propuesta de mejora: UTM en vez de Mikrotik para segmentar las redes, analizar la navegación y hacer un análisis de antivirus a nivel perimetral. También recomendamos un antivirus de fabricante distinto al del firewall pero el mismo en servidores y PCs. Revisamos políticas de directorio activo y actualizamos el sistema de copias de seguridad a pruebas de ransomware. Con todo esto:
Ponemos un cluster de firewalls, no uno sino dos. No llegamos a segmentar la red ni revisamos las políticas ya que es algo más lento, pero si integramos el sistema de copias de seguridad de manera urgente con Reborn. Quedamos en que nos llamen cuando quieran implementar el resto de cosas pero no llaman.
Llamamos un día y le habían vuelto a cifrar el servidor de ficheros. Recuperamos los datos desde el backup pero los logs de Reborn indicaban fecha/hora/IP de cada acción sobre cada fichero por lo que identificamos el usuario y la IP. Esta IP no era una IP del servidor, sino de un rango desconocido. Mirando, en el firewall descubrimos actividad P2P. Esta era por una conexión del señor a su casa, y salía a internet a través de la red corporativa.
La seguridad no atiende de días de la semana (los que iba el informático). De haber sabido esta conexión la topología de la red habría sido distinta y se hubiera optado por otra opción. En este incidente se reinstaló la máquina sin extraer evidencias ni analizarlas.
Caso Desde Rusia con amor
Fue en una empresa del sector de la construcción y en diciembre del 2019 estaban valorando a Reborn para sus copias de seguridad. En marzo de 2020 me llama y me dice que le han hackeado.
Le llamo y me dice que las copias de seguridad también están comprometidas y que los sistemas no arrancan. Habían cifrado la BIOS y el acceso al arranque de la máquina, incluso la tabla de particiones. Le pido que me mande alguno de los discos duros cifrados, son ficheros vmdk y FTK Imager no detecta nada, ni particiones ni sistemas de ficheros, así como la tabla de particiones que estaba inaccesible.
La empresa contaba con un ciberseguro. La aseguradora contactó con el ciberdelincuente dio y signos de conocer bien la red y los contenidos. Finalmente no pagaron el rescate y no recuperaron la información, ya que partieron de una copia de seguridad que no se cifró y de otras cosas viejas que tenían. Contrataron Reborn y el ciberseguro no les devolvió la totalidad de las pérdidas, por lo que cuidado con estos seguros.
En este caso, el ransomware cifró el MBR Locker. Podemos apreciar una profesionalización de los ciberdelincuentes y que los seguros si bien pueden llegar a pagar dinero, no nos devuelven la información. Es imprescindible contar con un backup confiable.
¿Todavía no formas parte de C1b3rWall Academy? El contenido es gratuito, únete a otras 30.000 personas desde este enlace.
Si te interesa este tema, puedes consultar la información y cursar el Máster en Ciberseguridad o ver la oferta de másteres desde aquí.
Ponente: Lorenzo Martínez Rodríguez
Director de la empresa Securízame, ingeniero informático por la Universidad de Deusto, colegiado por el Colegio Profesional de Ingenieros en Informática de La Rioja y miembro del ANCITE.
¿Cuál es tu reacción?
![like](https://wdiarium.com/assets/img/reactions/like.png)
![dislike](https://wdiarium.com/assets/img/reactions/dislike.png)
![love](https://wdiarium.com/assets/img/reactions/love.png)
![funny](https://wdiarium.com/assets/img/reactions/funny.png)
![angry](https://wdiarium.com/assets/img/reactions/angry.png)
![sad](https://wdiarium.com/assets/img/reactions/sad.png)
![wow](https://wdiarium.com/assets/img/reactions/wow.png)