Forensic Challenge 2010 – Primer desafío forense (3 de 3 )

Captura 20

Después de un salto y una llamada (que introduce en la pila las direcciones de las "variables" del shellcode), se almacena con un pop la dirección del string "GetProcAddress" en EDX . Ahora, el shellcode puede resolver la dirección de memoria de todas las funciones externas que necesita.

Lo primero que intenta hacer es encontrar el ImageBase de la librería kernel32.dll para obtener la dirección de la función getprocaddress. No voy a entrar en más detalles sobre la forma de obtener esta dirección, aunque podéis encontrar más info aquí.

Después de que el shellcode haya encontrado "GetProcAddress" en el array AddressOfNames, intentará resolver la dirección de la función a través del siguiente código:

Captura 21

Básicamente, el shellcode resuelve 3 funciones de la librería kernel32.dll (CreateProcessA, LoadLibraryA y ExitThread) y 5 de WS2_32.dll (WSASocketA, bind, listen, accept y closesocket).

Una vez que el código ha importado todo lo que necesita, comienza su "trabajo":

Captura 22

Lo primero que hace es crear un socket y luego utiliza llamadas a "bind" (la función que asocia una dirección con un socket) sobre ese socket para definir un parámetro que contendrá el puerto TCP que se va a usar: el 1957. Las llamadas a la función "listen" preparan al socket para recibir conexiones.

Captura 23

A continuación, se produce una llamada a CreateProcessA con el parámetro lpCommandLine establecido a "cmd" y a una entrada estándar, una salida y un manejador de errores redirigidos al socket recién creado.

El exploit ya ha creado una shell de comandos asociada al puerto tcp 1957 en la víctima, que es ejecutada con los mismos derechos del proceso explotado (en este caso, SYSTEM).

Octava pregunta contestada.

9. ¿Piensas que se ha utilizado un honeypot para simular una víctima vulnerable? ¿Por qué?

El sistema atacado es, efectivamente, un honeypot. Ya hemos obtenido algunas pistas para sostener esta teoría: si recordáis, la herramienta p0f utilizada en el apartado 1 nos indicaba que el equipo atacado era un sistema Linux. Sin embargo, durante todo el análisis hemos visto que, aparentemente, el sistema era Windows... Teniendo en cuenta que p0f realiza un análisis del tamaño de los paquetes, el TTL inicial o el tamaño de los paquetes SYN, creo que me fiaré de su análisis.

Otra pista la hemos obtenido en la captura 16. Si os dáis cuenta, el host atacante proporciona la ip 0.0.0.0 para descargar el archivo malicioso desde el FTP. Sin embargo, la víctima es capaz de corregir este error y conectarse a la ip del atacante para obtener el fichero en cuestión...

Novena pregunta contestada.

10. ¿Hubo malware implicado? ¿Cuál es su nombre? (No se pide un análisis detallado del malware)

Como se ha visto, el archivo descargado del servidor FTP es el ejecutable smss.exe, que en este caso es malware (existe un fichero con el mismo nombre en la carpeta C:\Windows\System32 de los sistemas Windows). Examinando el fichero con diversos antivirus, la respuesta mayoritaria es que se trata de Backdoor:Win32/Rbot

Décima pregunta contestada.

11. ¿Piensas que el ataque es manual o automatizado?

Casi con toda seguridad, el ataque ha sido automatizado. Difícilmente una persona habría podido completar el ataque en 16 segundos (captura 11). Además, un ataque manual difícilmente introduciría una ip 0.0.0.0 para conectar al servidor.

Undécimapregunta contestada.

Hasta aquí el primer desafío. Espero que os haya gustado.

Comparte este artículo