Una gran entrada de neo:
El contenido de este artículo se corresponde con mi propuesta de solución a la prueba de análisis forense planteada por el
inteco.
Los ficheros correspondientes a cada una de las pruebas, incluyendo el
volcado de la memoria ram utilizado en este análisis, estan disponibles
gracias a un compañero de la lista de correo de la rooted desde el
siguiente
enlace.
Importante recalcar que he tenido que modificar e incluso en ocasiones
eliminar información que considero superflua para adaptarme a las
limitaciones de formato impuestas por el tema del blog.
Indicar si la máquina está comprometida y
en caso afirmativo con qué tipo de código malicioso, aportando las
pruebas encontradas del mismo.[15%]
La máquina ha sido comprometida y para ocultar la ejecución de
determinados comandos a la vista de un posible análisis del sistema "en
caliente" se ha utilizado el rootkit FUto.
Analizando mediante volatility el listado de los procesos que se
encontraban en ejecución en el sistema en el momento de realizar el
volcado de la memoria física obtenemos:
# python vol.py -f imagen.dd pslist
Volatile Systems Volatility Framework 2.3_beta
Offset(V) Name PID PPID Thds Hnds Start
---------- ----------------- ------ ------ ------ -------- --------------------------
0x81233bd0 System 4 0 49 234
0x810dc368 smss.exe 524 4 3 19 2009-10-24 10:48:21 UTC+0
0x810d89a0 csrss.exe 596 524 10 231 2009-10-24 10:48:26 UTC+0
0x810be578 winlogon.exe 620 524 18 491 2009-10-24 10:48:27 UTC+0
0x810ec620 services.exe 664 620 14 235 2009-10-24 10:48:28 UTC+0
0xffb78150 lsass.exe 676 620 14 268 2009-10-24 10:48:29 UTC+0
0xffb538e0 vmacthlp.exe 844 664 1 24 2009-10-24 10:48:31 UTC+0
0x810cb1d0 svchost.exe 892 664 6 117 2009-10-24 10:48:33 UTC+0
0x810d3460 svchost.exe 960 664 9 193 2009-10-24 10:48:33 UTC+0
0x810d9a78 svchost.exe 1068 664 23 463 2009-10-24 10:48:34 UTC+0
0x810a2c90 svchost.exe 1096 664 6 60 2009-10-24 10:48:34 UTC+0
0xffb44638 svchost.exe 1220 664 10 153 2009-10-24 10:48:34 UTC+0
0xffb37278 VMwareService.e 1452 664 3 129 2009-10-24 10:48:37 UTC+0
0xffb7e4b8 explorer.exe 1704 1680 12 274 2009-10-24 10:51:05 UTC+0
0xffb19228 VMwareTray.exe 1780 1704 1 26 2009-10-24 10:51:07 UTC+0
0xffb17210 VMwareUser.exe 1788 1704 4 72 2009-10-24 10:51:07 UTC+0
0xffb153c0 cmd.exe 1012 1704 1 20 2009-10-24 11:01:34 UTC+0
0x81067da0 win32dd.exe 1020 1012 1 21 2009-10-24 11:01:34 UTC+0
De la salida anterior, similar al resultado obtenido mediante el
administrador de tareas de Windows, podemos concluir que se ha utilizado
el binario win32dd.exe para realizar el volcado de la memoria. Dado que
dicho binario se ejecuta desde la línea de comandos tiene sentido la
aparición de un proceso de nombre cmd.exe. Para confirmar este punto, y
de nuevo mediante volatility, comprobaremos los programas ejecutados en
el sistema desde la "shell":
# python vol.py -f imagen.dd cmdscan
Volatile Systems Volatility Framework 2.3_beta
**************************************************
CommandProcess: csrss.exe Pid: 596
CommandHistory: 0x4e50d8 Application: cmd.exe Flags: Allocated
CommandCount: 0 LastAdded: -1 LastDisplayed: -1
FirstCommand: 0 CommandCountMax: 50
ProcessHandle: 0x2a4
Cmd #0 @ 0xfc32d8: Nd \Malware\FUto
Cmd #1 @ 0x4e2328: Ntart nc -d -L -p 31337 -e cmd.exe
Cmd #2 @ 0x4e2a10: N?N?
Cmd #3 @ 0x4e9068: Netstat -a ?N???N?N
Cmd #4 @ 0x4e91a0: ??
Cmd #5 @ 0x4e9cf8: in32dd.exe
Cmd #6 @ 0x4e1eb8: N?N?
Cmd #7 @ 0x4e2ce8: N?N-phd msdirectx.sys
Cmd #8 @ 0x4e9e38: md.exe
**************************************************
CommandProcess: csrss.exe Pid: 596
CommandHistory: 0xfcf400 Application: win32dd.exe Flags: Allocated
CommandCount: 0 LastAdded: -1 LastDisplayed: -1
FirstCommand: 0 CommandCountMax: 50
ProcessHandle: 0x330
Obtenemos nuevos datos que constituyen nuevas vías de investigación.
Parece que se han lanzado programas cuya ejecución se ha ocultado
mediante el uso del rootkit
FUto.
Confirmaremos este punto utilizando como cadena de búsqueda la ruta "\Malware\FUto":
# python vol.py -f imagen.dd filescan | grep Malware
Volatile Systems Volatility Framework 2.3_beta
Offset(P) #Ptr #Hnd Access Name
---------- ------ ------ ------ ----
0x00d14f90 1 0 R--r-d \Device\HarddiskVolume1\Malware\FUto\fu.exe
0x01d5e828 1 1 R--rw- \Device\HarddiskVolume1\Malware\FUto
0x027f0f00 1 0 R--r-d \Device\HarddiskVolume1\Malware\FUto\nc.exe
NOTA: la salida del comando anterior no mostraba la cabecera, la cual se
ha incluido para facilitar el análisis de los resultados obtenidos.
¿Tiene procesos, bibliotecas o módulos
ocultos en el sistema? En caso afirmativo indicar cuales con todos los
detalles de los mismos y los métodos de detección utilizados.[30%]
Tal como se extrajo de la respuesta a la pregunta anterior es obvio que
existen al menos un proceso y un modulo/driver en ejecución pero ocultos
por acción del citado rootkit. Para confimar la ejecución de netcat
utilizaremos volatility mediante un comando diferente, el cual realiza
un listado más exhaustivo de los procesos en ejecución:
# python vol.py -f imagen.dd psxview
Volatile Systems Volatility Framework 2.3_beta
Offset(P) Name PID pslist psscan thrdproc pspcid csrss session deskthrd
---------- ----------------- ------ ------ ------ -------- ------ ----- ------- --------
0x010a6620 services.exe 664 True True True True True True True
0x004038e0 vmacthlp.exe 844 True True True True True True True
0x02dfd278 VMwareService.e 1452 True True True True True True True
0x03da03c0 cmd.exe 1012 True True True True True True True
0x02086638 svchost.exe 1220 True True True True True True True
0x00ae3850 nc.exe 408 False True True False True True True
0x0108d460 svchost.exe 960 True True True True True True True
0x0105cc90 svchost.exe 1096 True True True True True True True
0x03e4a228 VMwareTray.exe 1780 True True True True True True True
0x009e3150 lsass.exe 676 True True True True True True True
0x01093a78 svchost.exe 1068 True True True True True True True
0x01021da0 win32dd.exe 1020 True True True True True True True
0x010851d0 svchost.exe 892 True True True True True True True
0x03b6d210 VMwareUser.exe 1788 True True True True True True True
0x01078578 winlogon.exe 620 True True True True True True True
0x00d144b8 explorer.exe 1704 True True True True True True True
0x010929a0 csrss.exe 596 True True True True False True True
0x01096368 smss.exe 524 True True True True False False False
0x011edbd0 System 4 True True True True False False False
La cabecera informa del tipo de análisis utilizado para realizar el
listado de procesos y la aparición de "False" determina si dicho método
consigue detectar el proceso en cuestión. Concretamente para netcat la
columna correspondiente al listado del comando pslist, ejecutado en la
sección anterior, confirma que no es capaz de detectarlo lo que explica
que no pudieramos verlo.
Veamos ahora si existe algún modulo/driver oculto, utilizando como
cadena de búsqueda datos extraídos de los comandos ejecutados desde
cmd.exe:
# python vol.py -f imagen.dd modscan | grep Malware
Volatile Systems Volatility Framework 2.3_beta
Offset(P) Name Base Size File
---------- -------------- ---------- -------- ----
0x0112e688 msdirectx.sys 0xfc3b6000 0x10000 \??\C:\Malware\FUto\msdirectx.sys
NOTA: la salida del comando anterior no mostraba la cabecera, la cual se
ha incluido para una mayor claridad en el análisis de los resultados
obtenidos.
Enlace a Rootkit.c, el cual forma parte de FUto y se correspondería, una vez compilado, con el driver msdirectx.sys en cuestión.
¿Existe algún tipo de indicio de
comunicaciones en el sistema que permitan el control remoto del mismo?
En caso afirmativo explicar detalladamente. (direcciones IP, puertos,
procesos, ruta de los ficheros implicados, comandos ejecutados,
privilegios en el sistema, etc.)[20%]
No se detectan conexiones en curso en el momento en que se obtuvo el
volcado de la memoria física del sistema, para lo cual ha vuelto a
ejecutarse volatility:
# python vol.py -f imagen.dd connscan
Volatile Systems Volatility Framework 2.3_beta
Offset(P) Local Address Remote Address Pid
---------- ----------------- ------------------ -----
Lo que no significa que no puedan establecerse, de hecho esa es la
finalidad de la ejecución del comando netcat, brindar una shell del
sistema a cualquiera que se conecte al puerto 31337 TCP de la máquina
comprometida:
# python vol.py -f imagen.dd sockscan
Volatile Systems Volatility Framework 2.3_beta
Offset(P) PID Port Proto Protocol Address Create Time
---------- ----- ------ ------ ---------- --------------- -------------------------
0x01020a78 4 445 6 TCP 0.0.0.0 2009-10-24 10:48:21 UTC+0
0x01020cc0 4 445 17 UDP 0.0.0.0 2009-10-24 10:48:21 UTC+0
0x01021538 1220 1900 17 UDP 127.0.0.1 2009-10-24 10:51:13 UTC+0
0x01056d80 960 135 6 TCP 0.0.0.0 2009-10-24 10:48:34 UTC+0
0x010e7500 4 137 17 UDP 192.168.150.130 2009-10-24 10:48:37 UTC+0
0x01109bf0 4 139 6 TCP 192.168.150.130 2009-10-24 10:48:37 UTC+0
0x0110c3c0 4 138 17 UDP 192.168.150.130 2009-10-24 10:48:37 UTC+0
0x01130cc0 1220 1900 17 UDP 192.168.150.130 2009-10-24 10:51:13 UTC+0
0x011c7508 408 31337 6 TCP 0.0.0.0 2009-10-24 10:56:47 UTC+0
0x0264babc 0 7266 8456 - 128.206.46.0 -
0x02a49608 1068 123 17 UDP 127.0.0.1 2009-10-24 10:48:38 UTC+0
0x02a49a40 1068 123 17 UDP 192.168.150.130 2009-10-24 10:48:38 UTC+0
La salida anterior confirma la asociación del puerto 31337 TCP con el
PID 408 (nc.exe) y el comando ejecutado desde al consola del sistema así
lo confirma:
# python vol.py -f imagen.dd cmdscan | grep nc
Volatile Systems Volatility Framework 2.3_beta
Cmd #1 @ 0x4e2328: Ntart nc -d -L -p 31337 -e cmd.exe
Extraiga los ficheros maliciosos
identificados en el sistema e indique los hash (SHA256) de los mismos y
la ruta donde están ubicados en el disco duro de la máquina.[20%]
No resulta posible volcar el binario de netcat desde la memoria ya que
el comando de volatility utilizado para ello indica que la página de
memoria donde se encontraba almacenado ha sido paginada:
# python vol.py -f imagen.dd filescan | grep nc.exe
Volatile Systems Volatility Framework 2.3_beta
0x027f0f00 1 0 R--r-d \Device\HarddiskVolume1\Malware\FUto\nc.exe
# python vol.py -f imagen.dd psscan | grep nc
Volatile Systems Volatility Framework 2.3_beta
0x00ae3850 nc.exe 408 388 0x00cba000 2009-10-24 10:56:47 UTC+0000
# python vol.py -f imagen.dd procexedump -p 408 -o 0x00ae3850 -D evidencias/
Volatile Systems Volatility Framework 2.3_beta
Process(V) ImageBase Name Result
---------- ---------- --------- ------
0xffaf6850 0x00400000 nc.exe Error: ImageBaseAddress at 0x400000 is paged
Sin embargo no ocurre lo mismo con el driver msdirectx.sys:
# python vol.py -f imagen.dd modscan | grep msdirectx.sys
Volatile Systems Volatility Framework 2.3_beta
0x0112e688 msdirectx.sys 0xfc3b6000 0x10000 \??\C:\Malware\FUto\msdirectx.sys
# python vol.py -f imagen.dd moddump --base=0xfc3b6000 -D evidencias/
Volatile Systems Volatility Framework 2.3_beta
Module Base Module Name Result
----------- -------------------- ------
0x0fc3b6000 UNKNOWN OK: driver.fc3b6000.sys
# cd evidencias/
# shasum -a 256 driver.fc3b6000.sys
a9af6231ed5b6f9a8c7e0a10b6d26a5f052b91a98436dddc5f6b1b02e5edf6ec driver.fc3b6000.sys
Enlace al análisis del fichero volcado utilizando virustotal.
Explicar cómo tiene persistencia en el sistema, aportando las evidencias encontradas.[15%]
No conozco en detalle el funcionamiento del rootkit en cuestión, pero
entiendo que lo más obvio sería garantizar su ejecución tras cada
reinicio del sistema mediante el registro de Windows. Puede confirmarse
que existe una clave para el servicio/driver msdirectx, pero su
ejecución aparece como deshabilitada (parámetro Start de la salida
mostrada a continuación):
# python vol.py -f imagen.dd printkey -K "ControlSet001\Services\msdirectx"
Volatile Systems Volatility Framework 2.3_beta
Legend: (S) = Stable (V) = Volatile
----------------------------
Registry: \Device\HarddiskVolume1\WINDOWS\system32\config\system
Key name: msdirectx (S)
Last updated: 2009-10-24 10:59:17 UTC+0000
Subkeys:
(S) Security
(V) Enum
Values:
REG_DWORD Type : (S) 1
REG_DWORD Start : (S) 4
REG_DWORD ErrorControl : (S) 1
REG_EXPAND_SZ ImagePath : (S) \??\C:\Malware\FUto\msdirectx.sys
REG_SZ DisplayName : (S) msdirectx
REG_DWORD DeleteFlag : (S) 1
En cuanto al backdoor mediante la ejecución de netcat sirviendo una
shell en el puerto 31337 lo más logico sería ejecutar dicho comando
desde la clave del registro que determina las aplicaciones que se
ejecutan con el inicio del sistema, o incluso utilizando la clave
asociada a Winlogon, pero no resulta posible confirmar ninguna de las
hipotesis anteriores dado que la clave del registro correspondiente a
HKLM\Software no estaba cargada en memoria cuando se obtuvo el fichero
de volcado proporcionado.
Registro de Windows, svchost y malware.
Despedida y cierre
Tal como he comentado al principio ésta es mi solución, y no tiene
porque ser la correcta, o al menos no todo lo correcta que debería, así
que ya sabes, se aceptan todo tipo de críticas ... eso sí,
preferiblemente constructivas :)
Fuente:http://neosysforensics.blogspot.com/2013/06/analizando-un-trozito-de-memoria.html
Entradas
