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
No hay comentarios:
Publicar un comentario