En este post resolvemos Command & Control, level 2. Es muy sencillo de realizar, y además ayuda a usar volatility para analizar archivos DMP en Kali linux. ¡Empezamos!
Introducción a Command & Control level 2
Otro de los lugares donde se pueden realizar retos de hacking, CTF y llevar un control de tus progresos, es la página Root Me. En este portal te puedes dar de alta para acceder a sus ejercicios de hacking éticos.
Hoy vamos a resolver uno muy fácil, pero que necesita al menos de unos breves conocimientos de alguna herramienta para analizar ficheros de volcado de memoria en formato .dmp.
La herramienta en cuestión es volatility. Es extremadamente potente para este uso. Así que en este por podremos ver una breve introducción de algún argumento básico para usarla.
El enunciado del ejercicio indica que tenemos un volcado de memoria en un fichero y que queremos echar un vistazo al log del antivirus. Por desgracia, olvidamos apuntar el nombre del hostname del equipo. El reto trata de sacarlo del volcado de memoria.
El archivo que poseemos se llama ch2.dmp.
Vamos a realizar el ejercicio de dos formas: la rápida y visceral, y la lenta pero más interesante.
Resolver Command & Control level 2 por la vía rápida
Una vez que tenemos el archivo ch2.dmp en Kali, con un simple comando de volatility se puede sacar todo lo que hay en las variables de la memoria que contienen la palabra clave que nos interesa, que no es otra que COMPUTERNAME. Para ello, vamos a usar el argumento envars y filtrar con un grep ‘COMPUTERNAME’. La sentencia quedaría así desde el terminal de Kali:
root@kali:~/Documentos/RootMe# volatility -f ch2.dmp envars | grep 'COMPUTERNAME'El problema es que, al no usar un perfil de sistema operativo de la máquina, volatility no podrá sacar la información correcta. Por eso primero deberemos tratar de averiguar de qué sistema operativo se ha sacado el volcado de la memoria. Eso lo podemos conseguir con el argumento imageinfo. Eso nos arroja este resultado:
root@kali:~/Documentos/RootMe# volatility -f ch2.dmp imageinfo
Volatility Foundation Volatility Framework 2.6
INFO : volatility.debug : Determining profile based on KDBG search...
Suggested Profile(s) : Win7SP1x86_23418, Win7SP0x86, Win7SP1x86_24000, Win7SP1x86
AS Layer1 : IA32PagedMemoryPae (Kernel AS)
AS Layer2 : FileAddressSpace (/root/Documentos/RootMe/Command and Control level 2/ch2.dmp)
PAE type : PAE
DTB : 0x185000L
KDBG : 0x82929be8L
Number of Processors : 1
Image Type (Service Pack) : 0
KPCR for CPU 0 : 0x8292ac00L
KUSER_SHARED_DATA : 0xffdf0000L
Image date and time : 2013-01-12 16:59:18 UTC+0000
Image local date and time : 2013-01-12 17:59:18 +0100De ahí nos interesa la parte de Suggested Profile(s). Ya podemos utilizar el argumento –profile cuando queramos usar volatility, y probando veremos que Win7SP1x86 es el más acertado.
Con esto, ya podemos ejecutar volatility con el argumento envars y el profile correcto, de forma que son saldrá el dato de COMPUTERNAME que buscábamos:
root@kali:~/Documentos/RootMe# volatility -f ch2.dmp --profile=Win7SP1x86 envars | grep 'COMPUTERNAME'
Volatility Foundation Volatility Framework 2.6
560 services.exe 0x001207f0 COMPUTERNAME WIN-ETSA91RKCFP
576 lsass.exe 0x002507f0 COMPUTERNAME WIN-ETSA91RKCFP
584 lsm.exe 0x001907f0 COMPUTERNAME WIN-ETSA91RKCFP
692 svchost.exe 0x002c07f0 COMPUTERNAME WIN-ETSA91RKCFP
764 svchost.exe 0x002b07f0 COMPUTERNAME WIN-ETSA91RKCFP
832 svchost.exe 0x003007f0 COMPUTERNAME WIN-ETSA91RKCFPAhí podemos ver que el nombre del equipo relacionado con la ejecución de los procesos que tenía en marcha en tiempo de volcado de memoria era WIN-ETSA91RKCFP.
Con esto ya tenemos el FLAG que necesitábamos para pasar la prueba: WIN-ETSA91RKCFP.
Resolver el reto forense por la vía más lenta pero más didáctica
Esta vía tiene un par de pasos más, pero nos servirá para ver mejor cómo funciona volatility y cómo mirar el registro de Windows de la máquina de la que ha salido el volcado de memoria.
El primer paso es como en el caso anterior. Hay que identificar primero cuál es el sistema operativo de la máquina que vamos a analizar, pues hay que indicarle a volatility con el argumento profile cómo está estructurada la información a minar. Así, pues, con imageinfo lo chequeamos:
root@kali:~/Documentos/RootMe# volatility -f ch2.dmp imageinfo
Volatility Foundation Volatility Framework 2.6
INFO : volatility.debug : Determining profile based on KDBG search...
Suggested Profile(s) : Win7SP1x86_23418, Win7SP0x86, Win7SP1x86_24000, Win7SP1x86
AS Layer1 : IA32PagedMemoryPae (Kernel AS)
AS Layer2 : FileAddressSpace (/root/Documentos/RootMe/Command and Control level 2/ch2.dmp)
PAE type : PAE
DTB : 0x185000L
KDBG : 0x82929be8L
Number of Processors : 1
Image Type (Service Pack) : 0
KPCR for CPU 0 : 0x8292ac00L
KUSER_SHARED_DATA : 0xffdf0000L
Image date and time : 2013-01-12 16:59:18 UTC+0000
Image local date and time : 2013-01-12 17:59:18 +0100Como en el caso anterior, el perfil que podemos usar sugerido es Win7SP1x86.
Tras eso, vamos a buscar el nombre del equipo de otra forma. Este segundo sistema del que hablamos se basa en encontrar en la memoria del sistema el registro de Windows de ComputerName. En este ejemplo se puede ver qué key lo contiene:
Como se puede ver en la imagen, en HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\ComputerName\ComputerName he señalado en azul la clave que contiene el nombre de un equipo en Windows 10. Este es un ejemplo ficticio para que veas dónde está dicha clave. Es esta imagen se puede comprobar que el ComputerName es DESKTOP-FKMCG77.
Pues bien, con esta idea, vamos a buscar la clave en el registro dentro del volcado de memoria que contiene el nombre del equipo. Para ello, lo primero que tenemos que hacer es usar el argumento hivelist del volatility:
root@kali:~/Documentos/RootMe# volatility hivelist -f 'ch2.dmp' --profile=Win7SP1x86
Volatility Foundation Volatility Framework 2.6
Virtual Physical Name
---------- ---------- ----
0x8ee66740 0x141c0740 \SystemRoot\System32\Config\SOFTWARE
0x90cab9d0 0x172ab9d0 \SystemRoot\System32\Config\DEFAULT
0x9670e9d0 0x1ae709d0 \??\C:\Users\John Doe\ntuser.dat
0x9670f9d0 0x04a719d0 \??\C:\Users\John Doe\AppData\Local\Microsoft\Windows\UsrClass.dat
0x9aad6148 0x131af148 \SystemRoot\System32\Config\SAM
0x9ab25008 0x14a61008 \SystemRoot\System32\Config\SECURITY
0x9aba79d0 0x11a259d0 \??\C:\Windows\ServiceProfiles\LocalService\NTUSER.DAT
0x9abb1720 0x0a7d4720 \??\C:\Windows\ServiceProfiles\NetworkService\NTUSER.DAT
0x8b20c008 0x039e1008 [no name]
0x8b21c008 0x039ef008 \REGISTRY\MACHINE\SYSTEM
0x8b23c008 0x02ccf008 \REGISTRY\MACHINE\HARDWARE
0x8ee66008 0x141c0008 \Device\HarddiskVolume1\Boot\BCDCon estos resultados podemos ver que en la dirección virtual 0x8b21c008 empieza la clave de registro \REGISTRY\MACHINE\SYSTEM, que es la clave que nos interesa. Por ello, ahora vamos a ir indagando poco a poco para llegar a HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\ComputerName\ComputerName.
Para ello, usaremos la opción -o [dirección_de_memoria] para ir mirando en las claves de registro que queremos alcanzar. Por ejemplo, con el siguiente comando podemos ver qué otras claves siguen a \REGISTRY\MACHINE\SYSTEM (que en este caso está en la dirección de memoria 0x8b21c008):
oot@kali:~/Documentos/RootMe# volatility printkey -o 0x8b21c008 -f 'ch2.dmp' --profile=Win7SP1x86
Volatility Foundation Volatility Framework 2.6
Legend: (S) = Stable (V) = Volatile
----------------------------
Registry: \REGISTRY\MACHINE\SYSTEM
Key name: CMI-CreateHive{F10156BE-0E87-4EFB-969E-5DA29D131144} (S)
Last updated: 2013-01-12 16:37:53 UTC+0000
Subkeys:
(S) ControlSet001
(S) ControlSet002
(S) MountedDevices
(S) RNG
(S) Select
(S) Setup
(S) WPA
(V) CurrentControlSet
Con esto vemos que las subclaves son ControlSet001, ControlSet002, MountedDevices…
Como hemos visto en el ejemplo anterior de Windows 10, debemos ver el contenido de ControlSet001. Para ello usamos la opción -K como se muestra aquí:
root@kali:~/Documentos/RootMe# volatility printkey -o 0x8b21c008 -K 'ControlSet001' -f 'ch2.dmp' --profile=Win7SP1x86
Volatility Foundation Volatility Framework 2.6
Legend: (S) = Stable (V) = Volatile
----------------------------
Registry: \REGISTRY\MACHINE\SYSTEM
Key name: ControlSet001 (S)
Last updated: 2013-01-12 00:58:47 UTC+0000
Subkeys:
(S) Control
(S) Enum
(S) Hardware Profiles
(S) Policies
(S) services
Ahora podemos ver que dentro de \REGISTRY\MACHINE\SYSTEM\ControlSet001, le siguen las claves Control, Enum, Hardware Profiles, etc…
Pues nada, podemos ahorrar tiempo e ir directamente a la clave final que contiene ComputerName, como vimos en el ejemplo de la máquina de Windows 10:
root@kali:~/Documentos/RootMe# volatility printkey -o 0x8b21c008 -K 'ControlSet001\Control\ComputerName\ComputerName' -f 'ch2.dmp' --profile=Win7SP1x86
Volatility Foundation Volatility Framework 2.6
Legend: (S) = Stable (V) = Volatile
----------------------------
Registry: \REGISTRY\MACHINE\SYSTEM
Key name: ComputerName (S)
Last updated: 2013-01-12 00:58:30 UTC+0000
Subkeys:
Values:
REG_SZ : (S) mnmsrvc
REG_SZ ComputerName : (S) WIN-ETSA91RKCFPAquí observamos la que la clave de ComputerName contiene el resultado esperado: WIN-ETSA91RKCFP.
Este método es un poco más largo, pero nos da conocimiento de cómo mirar las claves del registro de la máquina de la que hemos obtenido el volcado de memoria. De este registro, se puede encontrar mucha más información que podría ser de utilidad en un futuro.
Así hemos resuelto Command & Control, level 2. ¿Qué te parece? ¿Interesante?
Deja una respuesta