martes, 19 de enero de 2021

Reto Forense - HTB: No Place To Hide o ¡Logs en RDP!, ¿estas seguro?

 

Pepito: Logs de RDP, ¡que Dios nos pille confesados!

Juanito:Que si, te vuelvo a repetir

Pepito: Y después de esto…

Juanito:Después de esto, encontré un reto en HTB que trataba precisamente de esto.

Pepito: ¿Cómo lo resolviste?

 

Juanito:Lo resolví gracias a la herramienta denominada: bmc-tools.py.

Pepito: ¿Pero cómo llegaste hasta dicha herramienta?

 

Juanito:Gracias a la búsqueda del magic number del archivo, que por cierto es: rdp8bmp.

Simplemente con poner el magic number en San Google podrás encuentrar en una de las entradas referencia al proyecto de Github.

Pepito: Pero, ¿logs de RDP?

 

Juanito:Pues sí, desde la versión 5.0 de RDP, Microsoft introdujo un mecanismo de caché para mapas de bits.

 

El objetivo era fue reducir la latencia de las comunicaciones entre el servidor RDP y el cliente RDP, por lo que las imágenes eran trasferidas al disco duro del cliente RDP y luego este la mostraba por pantalla.

 

Desde Windows 7, los archivos cacheados se encuentran ubicados en: "% USERPROFILE% \ AppData \ Local \ Microsoft \ Terminal Server Client \ Cache \".

 

En dicha ubicación nos podemos encontrar archivos de tipo “binario”, con la siguiente nomenclatura: cache{dddd}.bin (dddd = cuatro dígitos incrementales que comienzan desde 0000). Estos archivos pueden llegar a pesar cada uno: 100MB

 

En cuanto a la estructura de estos archivos, estos  tienen un encabezado fijo que es claramente identificable gracias al magic number: RDP8bmp, como ya hemos visto al hacer el reto. Tras el magic number, veremos un carácter nulo seguido de cuatro bytes correspondientes a una versión, es decir, el encabezado tiene doce bytes.

 

Cada elemento gráfico tiene un encabezado de tamaño reducido en comparación con los archivos con extensión ".bmc"ver NOTA:

 

·         un hash del elemento gráfico almacenado en ocho bytes

·         el ancho del elemento gráfico almacenado en dos bytes

·         la altura del elemento gráfico almacenado en dos bytes

 

Los datos subyacentes a cada elemento gráfico están en formato de 32 bpp.

----------------------------------------------------------------------------------------------------------------------------------------------------------- 

 

 

 

 

 

 

 

 

 

 

 

 

NOTA: Hasta Windows XP, la caché se encontraba en: "%USERPROFILE%\Local Settings\Application Data\Microsoft\Terminal Server Client\Cache\".

 

En dicha ubicación, se podían encontrar los siguientes archivos, que podían alcanzar hasta 10 MB de peso.

 

·         "Bcache2.bmc" que contiene los elementos gráficos en calidad de 8 bpp,

·         "Bcache22.bmc" que contiene los elementos gráficos en calidad de 16 bpp,

·         "Bcache24.bmc" que contiene los elementos gráficos en calidad de 32 bpp;

 

Estos archivos ".bmc" no tienen ningún encabezado fijo que permita su identificación inmediata, pero cada elemento gráfico en su interior tiene un encabezado de veinte bytes estructurado de la siguiente manera:

 

·         un hash del elemento gráfico almacenado en ocho bytes

·         el ancho del elemento gráfico almacenado en dos bytes

·         la altura del elemento gráfico almacenado en dos bytes

·         el tamaño en bytes de los datos que siguen al encabezado y que corresponden a la imagen almacenada en cuatro bytes

·         los parámetros específicos para el elemento gráfico almacenados en cuatro bytes. Uno de ellos define si el contenido de la imagen está comprimido o no, aunque se desconoce el algoritmo de compresión, por lo que ante una imagen comprimida no es posible recuperar los datos.

 

Si quieres más información, e incluso desarrollar tu propia herramienta en powershell, puedes ver las siguientes URL:

 

https://www.cert.ssi.gouv.fr/actualite/CERTFR-2016-ACT-017/

https://cbtgeeks.com/2018/05/22/digital-forensics-on-rdp-cache/

 

-----------------------------------------------------------------------------------------------------------------------------------------------------------

Pepito: Y el reto, ¿cómo fue?

Juanito: Pues ya te digo, aplique la herramienta y obtuve está foto que tengo en el móvil. Mira, mira…


                Y mira esta:

En cualquier caso

Lo que hagas con la información es cosa tuya, no mía... pero ten conciencia


lunes, 11 de enero de 2021

Reto Forense - HTB: Persistence

 

En este reto de HTB, lo primero que nos encontramos es un archivo con magic number: regf, es decir, un archivo de registro de Windows incompleto. Por lo tanto, ni podemos leerlo abiertamente con un editor hexadecimal ni con un intérprete ni mucho menos podremos leerlo directamente abriéndolo con el registro de Windows.


Pero eso no es problema, buscando en Internet no sólo encontramos la estructura de este tipo de archivo: https://www.taksati.org/regf/, sino también un parser de dicho archivos, así como ayuda para su uso:

·         https://cyberforensicator.com/2018/01/13/carving-fragmented-registry-files/

·         https://dfir.ru/tools/

·         https://github.com/msuhanov/yarp

 

Así que, instalamos la herramienta: yarp, y lanzamos el comando: yarp-print, para poder leer el contenido del archivo.


Para una mejor inspección, salvamos el contenido en un archivo mediante el comando: yarp-print <fichero> >> <fichero a almacenar>

Una vez obtenido lo que buscamos, y sabiendo que las flag de HTB son del estilo: HTB{….}, y que a la gente que pone los retos le gusta sobremanera la codificación en base64, buscamos dentro del archivo las cadenas en base64 que comiencen por: SFRC = HTB.

Al hacerlo encontramos una cadena:


DE INTERES: la cadena pertenece al nombre de un archivo, que será ejecutado siempre que el sistema se inicie, por estar dentro de: Software\Microsoft\Windows\CurrentVersion\Run

Si decodificamos dicha cadena obtenemos:


Parece que la intuición no ha fallado.

 

En cualquier caso…

Lo que hagas con la información es cosa tuya, no mía... pero ten conciencia.