lunes, 15 de enero de 2024

Detección de intrusión. Reverse Shell escondida en macros.

Hola a todos he creado este artículo a raíz de uno de los ejercicios que he puesto a mis alumnos de la asignatura de Gestión de Respuesta Frente a Incidentes de Seguridad dentro del Certificado de Profesionalidad de Castilla La-Mancha, en la resolución de este caso forense pretendo mostrar cómo llevar a cabo un ejercicio forense para descubrir qué ha sucedido durante un incidente. En el siguiente artículo se podrá ver cómo se tratan las evidencias y qué herramientas usamos para descubrir lo sucedido y, con ello, realizar un informe del caso.

Autor: David Bernal

Twitter: @db3rn4l.

Linkedin: https://www.linkedin.com/in/davidbernal89/


Antecedentes:

La empresa Renter nos ha contratado para realizar un ejercicio forense en el que, según dice la empresa, creen que el ordenador de Raúl ha sido vulnerado.

Raúl ha notado que su equipo ha emitido algunas ventanas azules que se cierran rápidamente y ralentización del equipo mientras está trabajando.

El sujeto afectado es un empleado administrativo que se encarga de gestionar los préstamos de las furgonetas de la empresa, por lo que no tiene conocimientos informáticos, más allá de los básicos para realizar su trabajo.

Renter es una empresa (ficticia) que se dedica a prestar furgonetas en alquiler.

 

Evidencias:

Como evidencias disponemos de un triage completo realizado mediante la herramienta Windows Live Response de Brimor Labs que se puede descargar del siguiente enlace https://www.brimorlabs.com/tools/.

Windows Live Respones (en adelante WLR) es una herramienta gratuita GNU desarrollada por Brian Moran que permite la recolección de la memoria volátil (memoria RAM), la realización de un triage mediante el cual se obtienen números registros volátiles importantes y una imagen del disco duro del equipo afectado.


En el caso en el que nos encontramos, disponemos de un triage completo, compuesto por las imágenes forenses (memoria e imagen del disco) y los datos volátiles obtenidos en vivo, tal y como se puede observar en las imágenes inferiores.

Directorio ForensicImages:

         
Directorio LiveResponseData:

Análisis de evidencias. Triage:

Comenzamos revisando el archivo system_info.txt dentro de la carpeta BasicInfo.

En este archivo obtendremos datos importantes tales como el sistema operativo, nombre del equipo, direccionamiento IP y la zona horaria del sistema, dato muy importante que nos ayudará a establecer una línea temporal con los eventos ocurridos dentro del sistema.

System Info:


El siguiente paso que damos es echar un vistazo dentro de los procesos del sistema, para ello abrimos el archivo PsList.txt.

En la tabla de procesos que se puede ver en el archivo observamos un proceso powershell, algo bastante sospechoso ya que Raúl no tiene conocimientos suficientes como para realizar trabajos con esta herramienta.

Desgraciadamente el archivo PsList.txt no nos muestra el proceso padre de cada proceso para saber de dónde puede provenir la ejecución de este proceso powershell.

PsList.txt:

Ya disponemos de un hilo de donde tirar, por lo que deberíamos echar un vistazo a todo lo relacionado con powershell y más concretamente con el proceso con PID 360, pero vamos a dejarlo aparcado un poco y, para que no se nos escape nada, vamos a continuar mirando más archivos obtenidos en el triage.

Otra cosa muy importante que revisar son siempre las conexiones de red de los equipos, el triage de WLR, ofrece varios archivos con registros de las conexiones de red que existen en el momento de la realización del triage.

Durante este ejercicio nos vamos a centrar en el archivo cports.html dentro de la carpeta NetworkInfo, que es un archivo realizado en HTML (visible desde un navegador web) mediante el cual se pueden apreciar las conexiones de red que realiza un equipo.

Si nos fijamos detenidamente se puede observar que, desde la IP de la máquina de Raúl, se realiza una conexión a la IP 151.12.4.11 mediante el proceso powershell al puerto 3601. Esta dirección IP no se corresponde a ninguna dirección IP de la empresa Renter, por lo que se está realizando contra un host de Internet… También es sospechoso el puerto ya que no se corresponde a ningún puerto conocido por ningún servicio al que acceda la empresa.

Adicionalmente podemos observar una conexión FTP a la misma dirección IP, lo que nos puede indicar que alguien ha estado transfiriendo archivos entre la máquina afectada y esa máquina desconocida.

cports.html:


Continuando con la revisión de los archivos del triage, esta vez miramos en el archivo LastActivityView.html dentro de la carpeta BasicInfo.

Este archivo refleja las últimas ejecuciones realizadas en el sistema, observamos las ejecuciones de powershell, PID (360) que tenemos apuntado y posteriormente revisaremos cuando analicemos la memoria volátil en profundidad y la ejecución del ftp nativo de Windows. Nos llama mucho la atención que un usuario básico de Windows, que hace labores administrativas, haga uso de la herramienta nativa de ftp de Windows (normalmente se utilizan aplicaciones del tipo WinSCP para realizar transferencias de archivos FTP), por lo que nos lo apuntamos.

También podemos comprobar que se ha realizado la ejecución del programa WINWORD.EXE (aplicación Word de office) y se ha abierto el archivo factura.doc, a estos registros no les vamos a hacer demasiado caso por el momento, ya que el PC es usado por una persona que suele realizar su trabajo diario con herramientas de office y maneja la facturación de sus clientes.






Análisis de evidencias. Eventos del sistema:

Llegados a este punto del análisis, nos vamos a dirigir a la imagen del disco duro del PC implicado para extraer los eventos del sistema.

Dentro de la Carpeta ForensicImages > DiskImage encontramos una serie de archivos con extensión *.drive.E0n, éstos son fragmentos de una imagen de disco duro realizada durante el triage con WLR, tal y como se puede ver en la imagen inferior.


Para poder montar la imagen de disco utilizamos la herramienta FTK Imager de AccessData que se puede descargar de forma gratuita del siguiente enlace https://accessdata.com/product-download/ftk-imager-version-4-5 tras registrarse.

Desde dentro de la herramienta elegiremos como origen Image File y seleccionaremos el primer E01 para montar el disco al completo.


Una vez montado, nos aparecerá el árbol completo de directorios del sistema como se puede ver en la siguiente imagen:


Accederemos a la ruta C:\Windows\System32\Winevt\Logs y extraeremos los eventos del sistema System.evtx y Microsoft-Windows-PowerShell%4Operational.evtx

Para poder visualizar los eventos del sistema tenemos varias herramientas, podemos tirar del propio visor de eventos de Windows, utilizar Full Event Log View de Nirsoft https://www.nirsoft.net/utils/full_event_log_view.html o mi preferido, Even Log Explorer https://eventlogxp.com/download.php

Event Log Explorer (en adelante ELE) es un programa de pago, pero que mediante registro te permite hacer uso de la solución durante un periodo de 30 días y una vez acabados puedes solicitar la ampliación de la licencia.

Para poder cargar los eventos en ELE, simplemente nos dirigimos a File > Open Log File > Standard y seleccionamos el archivo de eventos que queramos visualizar.

En este caso vamos a empezar por Microsoft-Windows-PowerShell%4Operational.evtx ya que en este archivo se guardan todas las ejecuciones realizadas a través de Powershell y nos interesa comprobar si se puede ver alguna ejecución de Powershell que demuestre las incidencias sobre las que se queja Raúl.

Lo primero que hacemos siempre que se trabaja con Event Log Explorer es ajustar la hora a UTC para no equivocarnos y a partir de ahí mentalmente se suman las horas para ajustar el tiempo a la hora que tenía el sistema, en este caso era UTC + 1 (Madrid) pero en horario de verano, es decir, 2 horas más.

Para ajustar el tiempo, nos dirigiremos a View > Time Correction  


Y aplicamos en UTC


A continuación, nos dirigimos a las 11:17 (15:17 UTC + 2) ya que el fichero LastActivityView.html mostraba una ejecución de Powershell a las 13:16 (UTC + 2) y se puede observar una ejecución de Powershell -e junto a un string de caracteres ilegible.

Observando que el string acaba en == se puede intuir que se trata de un string de texto codificado en Base64, por lo que nos dirigimos a la página web base64decode.org y lo pegamos aquí para descifrarlo.



Si miramos detenidamente el string resultante se puede apreciar que se crea un objeto de red en el que se establece un socket de conexión System.Net.Sockets.TCPClient("151.12.4.11",3601) hacia la dirección IP 151.12.4.11 al puerto 3601 (justamente la dirección IP que aparecía en el archivo cports.html) otorgando una Shell en Powershell de la máquina de Raúl, es decir, una Shell Reversa con la que el atacante ha obtenido el control de la máquina de Raúl.

También hemos revisado los eventos de seguridad del sistema de Raúl alojados en el archivo Security.evtx en el que no hemos visto conexiones entrantes hacia la máquina de Raúl, ni sesiones abiertas remotamente, ni creación de usuarios extraños dentro del sistema, lo que nos confirma que ha sido la máquina de Raúl la que se ha debido de conectar a la máquina del atacante ofreciéndole una Shell de Powershell.


Análisis de evidencias. Memoria:

Para analizar el volcado de memoria de la máquina de Raúl vamos a utilizar la herramienta Volatility concretamente la versión Stand Alone executable que se puede descargar aquí http://downloads.volatilityfoundation.org/releases/2.6/volatility_2.6_win64_standalone.zip

Volatility es una herramienta forense de análisis de memoria desarrollada en Python, lo que permite que pueda ser utilizada en cualquier plataforma que tenga Python instalado.

En este caso forense, vamos a usar la versión Stand Alone porque no necesitamos añadir plugins adicionales y no es necesario instalar Python para usarla.

Lo primero que se debe hacer para comenzar a analizar un volcado de memoria con Volatility es hallar el perfil del sistema operativo instalado, para ello Volatility cuenta con el comando “imageinfo”.

La sintaxis del comando sería la siguiente:

volatility.exe -f RAUL-PC_20220607_152508_mem.dmp imageinfo. 

  *Nota: La opción -f RAUL-PC_20220607_152508_mem.dmp, sirve para indicar la ruta del volcado de memoria.


El resultado nos arroja cuatro posibles perfiles, en este caso nos vamos a quedar con el perfil Win10x64_10586

Una vez obtenido el perfil vamos a continuar analizando la memoria en busca de los procesos en ejecución, si recordamos al principio del caso forense teníamos un proceso de Powershell con PID 360, el cual no sabemos cuál era su origen, es decir, su proceso padre. Para obtener un árbol de procesos en donde aparezcan los procesos clasificados utilizaremos el comando pstree y la salida del comando la vamos a mandar a un fichero que nos facilite su lectura.

La sintaxis del comando sería la siguiente: volatility.exe -f RAUL-PC_20220607_152508_mem.dmp --profile=Win10x64_10586 pstree > pstree.txt

Una vez obtenida la salida de pstree podemos observar que el proceso powershell.exe PID:360 es hijo del proceso WINDWORD.EXE con PID 3304.

La interpretación de lo anterior es que el usuario hizo uso de la aplicación WORD para abrir un archivo y a continuación se ejecutó el proceso powershell.exe, algo muy sospechoso.


A continuación, echamos un vistazo a las conexiones de red. Mirar las conexiones de red dentro de la memoria tiene la ventaja de que pueden quedar registros de conexiones que han sido cerradas y que no aparecen en los archivos de los triages.

Para ello ejecutamos el comando netscan y lo mandamos a fichero de la siguiente forma:

volatility.exe -f RAUL-PC_20220607_152508_mem.dmp --profile=Win10x64_10586 netscan > netscan.txt

De los registros que obtenemos podemos apreciar la conexión powershell contra la IP 151.12.4.11 al puerto 3601 y adicionalmente otra conexión a la IP 151.12.4.11 al puerto 21 la cual puede estar relacionada a la ejecución del ftp.exe nativo de Windows que vimos en el archivo LastActivityView.html




Tras haber analizado las conexiones y visto el árbol de procesos, vamos a pasar a analizar proceso por proceso. Para ello haremos uso del comando memdump que nos va a permitir volcar el área de memoria usada por un proceso y a partir de ese volcado extraeremos datos utilizando strings en Windows.

Para obtener el comando strings en Windows deberemos descargarlo del siguiente enlace: https://docs.microsoft.com/en-us/sysinternals/downloads/strings

Vamos a comenzar con el proceso WINWORD ya que nos interesa saber cuál es el archivo que que ha podido generar esa ejecución de Powershell. Para obtener el minidump del proceso 3304 ejecutamos el siguiente comando:

volatility.exe -f RAUL-PC_20220607_152508_mem.dmp --profile=Win10x64_10586 memdum -p 3304 -D .\dir


Una vez obtenido el minidump, haremos uso de Strings y filtraremos por “doc” para poder ver qué documentos se encontraba manejando el Word en ese momento.

Después de realizar el comando strings64.exe 3304.dmp | find “doc” obtenemos registros de que el archivo que estaba abierto por el proceso es factura.doc que se encontraba en la ruta C:\Users\Raul\Desktop\factura.docx como se puede apreciar en la siguiente imagen.



El siguiente proceso que vamos a analizar es el proceso 360 correspondiente a Powershell, para ello volcamos el área de memoria del proceso:

volatility.exe -f RAUL-PC_20220607_152508_mem.dmp --profile=Win10x64_10586 memdum -p 360 -D .\dir


Una vez obtenido el minidump vamos a tirar de Strings para intentar obtener información. Primero filtramos por “doc” y podemos observar que la persona que controlaba el proceso powershell comprimió la carpeta docs de Raúl en un fichero llamado exfil.zip, por lo que pudo haber robado información.


En el siguiente paso filtramos por “ftp” ya que si el atacante quiso robar información seguro que pudo haber utilizado el protocolo ftp tal y como vimos en el archivo LastActivityView.html y… bingo!, tal y como podemos ver en la imagen inferior el atacante ha extraído la información a través del protocolo FTP, además podemos ver cómo se conecta a la IP 151.12.4.11 la misma que vimos cuando extrajimos las conexiones de la memoria mediante el comando netscan con el usuario kali y la contraseña kali.


Análisis de evidencias. Registros de Ficheros:


Únicamente nos queda descubrir cómo ha podido llegar ese archivo malicioso al PC de Raúl, por lo que volvemos al FTK imager y extraemos la MFT ($MFT) de la raíz del sistema de ficheros.

La MFT o Master File Table, es una tabla que guarda los registros de todos los ficheros que están o han estado en el sistema junto con sus timestamps, es decir, las fechas de acceso, creación, modificación y cambios en los metadatos de los archivos.


Para poder leer la mft, primero debemos parsearla, es decir traducirla a un idioma que podamos interpretar, para ello vamos a hacer uso de la herramienta mftdump la cual es capaz de producir un archivo CSV con los registros de la MFT.

Para descargar la herramienta se hacía desde la web http://malware-hunters.net/freetools/, pero actualmente se encuentra caída por lo que podemos acceder mediante archive.org y descárgalo del siguiente enlace https://web.archive.org/web/20170223081622/http://malware-hunters.net/wp-content/downloads/MFTDump_V.1.3.0.zip

La sintaxis es muy básica simplemente con mftdump.exe $MFT -o resultado.csv obtendremos la tabla MFT lista para analizarla con nuestra aplicación de hoja de cálculo preferida.


En este caso yo he utilizado Excel y tras pasar los registros a columnas separados por tabulador, ordenarlos de más antiguos a más nuevos y filtrar por “factura” hemos encontrado un registro .lnk en los recents que justamente se encuentra debajo de bastantes registros de Thunderbird, lo que hace pensar que el cliente de correo electrónico ha podido tener algo que ver en la aparición de este archivo.

Decididos a analizar el correo electrónico de Raúl mediante FTK imager nos dirigimos a la ruta C:\Users\Raul\AppData\Roaming\Thunderbird\Profiles y nos exportamos su perfil de correo electrónico para poder analizarlo.

El correo electrónico procedente del cliente Thunderbird lo analizamos con la herramienta Mbox Viewer Free https://www.mboxviewer.com/. Esta es una herramienta cuya licencia tiene un coste, pero que permite un periodo de prueba de aproximadamente unos 15 días.

Abrimos la herramienta y cargamos la carpeta exportada con el perfil tal y como se puede ver a continuación.

Y vualá, ahí tenemos el correo electrónico de Raúl.

Si nos fijamos detenidamente Raúl suele recibir correos de la empresa cliente aliven.es, pero… en su buzón de entrada hay un correo desde el dominio a1iven.es, lo que parece claramente una suplantación de identidad.

Si abrimos el correo podemos observar que tiene como adjunto el archivo factura.doc.

 

Tras comprobar el correo nos dirigimos con FTK imager a la ruta C:\Users\Raul\Desktop\factura.doc y extraemos el archivo.

Una vez obtenido el archivo podemos analizarlo de varias formas. Una de ellas es subirlo a virustotal y obtendremos un análisis del archivo, tal y como podemos ver en la imagen inferior:


O con mucho cuidado y en un entorno controlado, podemos proceder a abrirlo y comprobar que el fichero tiene una macro en su interior con el comando que vimos en los eventos de powershell.


Fin.

lunes, 13 de junio de 2022

FIND-ME Root-Me Walkthrough

Últimamente le estoy pegando mucho a los retos forenses, ya que definitivamente creo que es con lo que más disfruto en el área de seguridad, y concretamente en una plataforma gratuita llamada Root-Me https://www.root-me.org/

Hoy os traigo la resolución del reto FIND-ME, de dificultad media/alta por el que nos darán 50 puntos si lo resolvemos: https://www.root-me.org/en/Challenges/Forensic/Find-me

Ojo comienza el spoiler.

Autor: David Bernal

Twitter: @db3rn4l.

Linkedin: https://www.linkedin.com/in/davidbernal89/

Premisas:

Maquina Find Me

El reto indica que tu hijo (no reconocido, entiendo…) es un geek que quiere demostrarte que tiene habilidades para ocultarte información. Un buen día te dejaste la sesión abierta y éste pillo aprovechó para gastarte una broma.

Vaya, que lo que debemos hacer es encontrar la contraseña de validación de algo en lo que parece ser un volcado de memoria.

Durante este reto voy a utilizar Caine y Windows10 con varias herramientas forenses para resolverlo, principalmente volatility 2.6 en Caine y Volatility Standalone en Windows.

Pulsamos en el botón start hte challenge y se nos descargará un archivo de nombre ch18.zip el cual, en su interior, contiene el volcado de memoria.

Análisis de memoria

Realizamos un imageinfo para obtener el perfil sugerido para trabajar con volatility: vol.py -f dump imageinfo.

Una vez obtenido el perfil, podemos comenzar a analizar la memoria. Yo, cuando no tengo ninguna pista más allá, me gusta empezar echando un primer vistazo a los procesos por si acaso hay algo que me salte a la vista. Lanzamos un pstree porque me gusta tener una lista, no solo de los procesos en ejecución, si no de las relaciones que puede haber entre ellos (por aquello de que puede aparecer un chrome.exe lanzando un powershell… por ejemplo).

Para sacar el árbol de procesos ejecutamos el comando:

vol.py -f dump --profile=Win7SP1x86_23418 pstree > pstree.txt


Como se puede ver en la imagen anterior existe un proceso TrueCrypt corriendo en la máquina. TrueCrypt es un conocido software de cifrado de datos que se empleó mucho hasta 2015 año en el que se detectó una vulnerabilidad en su código y se dejó de utilizar https://www.xataka.com/basics/que-truecrypt-que-paso-que-no-seguro-utilizarlo, también debo destacar que el proceso tryuecrypt.exe en memoria, en dispositivos Windows =< a Win7 almacenaba la contraseña de cifrado en memoria y mediante el plugin de Volatility “truecryptsummary” se puede revelar dicha contraseña.
 
vol.py -f dump --profile=Win7SP1x86_23418 truecryptsummary > truecryptsummary.txt



Gracias a truecryptsummary hemos obtenido la contraseña de cifrado, pero no tenemos ninguna referencia del archivo que contiene el volumen cifrado, es decir, del contenedor por lo que ahora comienza la búsqueda de la aguja en el pajar…

Se me ocurrió que el archivo puede que estuviese en memoria en el momento en el que se realizó la captura por lo que vamos a volcar el área de memoria del proceso truecrypt.exe (pid 3224) y vamos a intentar escarbar en él haciendo uso de strings.

vol.py -f dump --profile=Win7SP1x86_23418 memdump -p 3224 -D ./dir

Como el cifrado, lo ha tenido que haber realizado algún usuario se me ocurrió filtrar por “Users” y echar un vistazo.



strings ./dir/3224 | grep Users



De los datos obtenidos veo que hay un archivo llamado “findme” justo antes del History.xml de TrueCrypt, ¿coincidencia? Pues vamos a verlo.

Primero comprobamos si ese archivo se encuentra en memoria con el plugin filescan.

vol.py -f dump --profile=Win7SP1x86_23418 filescan | grep findme

 

Como ha habido suerte procedemos a extraerlo mediante el plugin dumpfiles, pasándole por parámetros la dirección física de la memoria en la que se aloja ese archivo.

vol.py -f dump --profile=Win7SP1x86_23418 dumpfiles -Q 0x000000001ee20110 -D ./dir/


El resultado del comando anterior nos devuelve un archivo.dat (archivo de datos), es decir es el mismo archivo “findme” solo que Volatility lo renombra de esta manera (https://github.com/volatilityfoundation/volatility/wiki/Command-Reference#dumpfiles).

Pasamos el archivo a la máquina Windows con TrueCrypt instalado y montamos el mismo introduciéndole la contraseña obtenida con el plugin “truecryptsummary”.

 


Una vez montado, nos dirigimos a la unidad y descubriremos que hay 3 ficheros.


En el txt no hay nada… 



En la imagen tampoco…

 


Sólo nos queda el .odt


Una vez un alumno me comentó que los archivos tanto *.odt  como *.docx, son como archivos comprimidos, por lo que se me ocurrió hacer una cosa.

Abrimos ese archivo con Winrar para ver qué es lo que tenía en su interior y, también, otro archivo *.odt mío para compararlos a ver si había diferencias y aquí está el resultado:


 

Hay una carpeta data en su interior que no suele encontrarse en este tipo de archivos, pues bien, accedemos a ella y descubrimos un archivo en su interior con nombre “my_safety_box” del cual no disponemos de ninguna referencia sobre qué puede tratarse.


Llegados a este punto, nos toca investigar qué más cosas puede haber dentro de la máquina que nos permitan intuir qué puede ser este archivo y recordé que en el pstree vi navegación de usuario a través del navegador Firefox.



Para poder extraer la navegación en memoria, se necesita de un plugin adicional que no se encuentra por defecto alojado dentro de Volatility, por lo que debemos clonar un repositorio que el usuario “superponible” ha dejado en su github.

git clone https://github.com/superponible/volatility-plugins

Una vez obtenidos los plugins, ejecutamos el siguiente comando:

vol.py --plugin=/home/dfir/Desktop/rootme/volatility-plugins -f dump --profile=Win7SP1x86_23418 firefoxhistory  --output=csv > firefoxhistory.csv

Obteniendo un archivo .CSV que al analizarlo con cualquier software que procese hojas de cálculo, nos permite ver que el usuario realizó varias búsquedas sobre keepass.


Para sacarnos de dudas, usamos el comando file de Linux con el que se nos sugiere que el tipo de archivo que tenemos delante es una base de datos de tipo KDBX, es decir, de tipo Keepass.


Lo siguiente es hallar la contraseña para poder abrir la base de datos de keepass, tras un rato revisando la memoria se me ocurrió que se podría intentar sacar los hashes de los usuarios del sistema y después crackearlos, ya que en la navegación del usuario se había accedido a Crackstation.net.

Para extraer los hashes, primero necesitamos obtener las direcciones virtuales de memoria de los hives del sistema SYSTEM y SAM, para esto debemos utilizar el plugin hivelist:

vol.py -f dump --profile=Win7SP1x86_23418 hivelist

Una vez obtenidas las direcciones de memoria procedemos a volcar los hashes NTLM de las contraseñas de los usuarios, para esto utilizamos el plugin hashdump y le pasamos las direcciones de memoria, con la opción -y la del SYSTEM y con la opción -s de la SAM.

vol.py -f dump --profile=Win7SP1x86_23418 hashdump -y 0x88c1a280 -s 0x901de008


Tras obtenerlas comprobamos una por una en Crackstarion.net obteniendo que la contraseña del usuario info es #1Gogfather.


Volvemos a la máquina Windows, abrimos Keepass, seleccionamos el archivo y probamos a pasarle la contraseña obtenida.



Y por suerte la base de datos se abre y aparecen unos 4240 registros en la sección Internet.


Como son demasiadas para probar una por una las exportamos a CSV para revisarlas detenidamente.

 

 Tras pasar el texto separado por comas a columnas aplicamos filtros.



Y filtramos por cada uno de los campos comprobando si hay alguna incongruencia y curiosamente en el campo de las contraseñas existe un registro que es mucho más grande que los demás.

 


Mirándolo muy de cerca se puede observar que acaba en “=” lo que hace suponer que pueda tratarse de un string encodeado en base64.


Lo intentamos decodear en caine con el comando à echo “string” | base64 --decode y nos un nuevo string en base64.

Como es una locura decodear esto de forma manual, se me ocurrió crear un pequeño script en Shellscript que tomase como referencia un archivo en el que escribo el base64 original y vaya decodeando un número limitado de veces.

Para ello creamos un archivo llamado base64code0


Pegamos el string


Creamos un fichero script llamado scriptdecode.sh que realice la operación de decodear el string, mandarlo a un archivo vacío y retomarlo, en este caso durante unas 30 veces.


Otorgamos permisos de ejecución


Lo ejecutamos.


Al finalizar la ejecución vamos a obtener unos 30 archivos como resultado, por lo que nos tocará revisarlos uno por uno.


En mi caso, accedemos al número 21 y ahí se encontrará la contraseña que necesitamos introducir en root-me para obtener los 50 puntos del reto.



Espero que os haya gustado.

Un saludo.