on

Análisis Forense de una Infección – PARTE III

Tal y como comentamos en el post anterior, en el escrito de hoy vamos a realizar un análisis dinámico del malware. Concretamente, hemos tomado el ejecutable A0029519.exe situado en:

System Volume Information_restore{2D9E3322-AD12-427C-8050-DC9B1714968D}RP126

con tamaño 42579 bytes y  hash sha1 2566f4de9d1f789314c0e67fcdc4f2d4778308d.

Una vez ya tenemos el especimen a analizar, hemos montado un pequeño laboratorio aislado de cualquier otra red, en la que hemos montado un red de máquinas virtualizadas, para ejecutar el malware en un entorno controlado y completamente monitorizado.

Para empezar, se puede intentar monitorizar los procesos creados justo después de la ejecución del especimen, así como ficheros creados o modificados, claves del registro creadas o modificadas, actividad de red, etc.

Durante el proceso, se ha detectado algo habitual en algunos especimenes de malware. Para evitar ser analizado, dificultan las tareas al analista, matando procesos típicos generados por herramientas como procmon, process xp, tcpview (y otras herramientas de Sysinternals típicamente utilizadas), wireshark, cmd, etc. habiéndose reiniciado el equipo en diversas ocasiones… Por ello, se han utilizado herramientas no reconocidas por el malware como son ICESword, regshot, tcpdump en otros equipos de la red…

¡Empecemos !

Analizando los procesos que se encuentran ejecutándose, observamos lo que ya sabíamos de los posts anteriores, las copias del malware situadas en el directorio “Documents and SettingsUserLocal SettingsApplication Data” entran en ejecución:

Listado de procesos identificados como copia del malware

A nivel de puertos abiertos, aparentemente parece ser que no se abre ningún puerto pudiendo descartar la posibilidad que el malware dispusiera de un backdoor que permitiera el acceso remoto al equipo.

Estado de las conexiones del sistema. Análisis de puertos abiertos

Como medida alternativa, se ha lanzado un nmap (nmap -sV -sS -p 0-65535 192.168.1.22) antes y después de infectar el equipo para poder ver así los puertos abiertos y visibles desde otros equipos, produciendo en ambos casos los siguientes resultados:

[sourcecode language=’plain’]
Starting Nmap 5.00 ( http://nmap.org ) at 2010-09-13 11:46 CEST
Interesting ports on 192.168.1.22:
Not shown: 65533 closed ports
PORT    STATE SERVICE      VERSION
135/tcp open  msrpc        Microsoft Windows RPC
139/tcp open  netbios-ssn
445/tcp open  microsoft-ds Microsoft Windows XP microsoft-ds
MAC Address: 00:0C:29:90:BC:05 (VMware)
Service Info: OS: Windows
Service detection performed. Please report any incorrect results at http://nmap.org/submit/
Nmap done: 1 IP address (1 host up) scanned in 26.05 seconds

[/sourcecode]

Los cuales, cuadran con los resultados de ICEsword y además, los procesos (PID) creados por el malware, no disponen de ningún puerto asociado.

Siguiendo con el proceso de análisis, si observamos los autoruns del registro, no descubrimos nada nuevo, ya que las claves que consulta la aplicación ICEsword son las mismas que habíamos consultado mediante regripper.

Contenido de las claves del registro – “Autoruns” del sistema

Sin embargo, podemos realizar un análisis más específico del registro, mediante la herramienta regshot, que nos permitirá realizar una foto del estado del registro antes y después de la infección. Pudiendo comparar diferencialmente los resultados de la primera y la segunda instantánea.

Realizando dicho análisis, se ha obtenido:

  • Claves añadidas: 23
  • Valores añadidos: 55
  • Valores modificados: 15

Destacando de entre los resultados obtenidos las siguientes modificaciones:

Claves Añadidas

[sourcecode language=’plain’]

HKUS-1-5-21-527237240-1682526488-839522115-1003SoftwareMicrosoftWindowsCurrentVersionPoliciesSystem

[/sourcecode]

Valores Añadidos

[sourcecode language=’plain’]

HKLMSOFTWAREMicrosoftWindowsCurrentVersionRunBron-Spizaetus: “”C:WINDOWSShellNewsempalong.exe””
HKLMSYSTEMCurrentControlSetServicesScheduleAtTaskMaxHours: 0x00000048

HKUS-1-5-21-527237240-1682526488-839522115-1003SoftwareMicrosoftWindowsCurrentVersionPoliciesExplorerNoFolderOptions: 0x00000001
HKUS-1-5-21-527237240-1682526488-839522115-1003SoftwareMicrosoftWindowsCurrentVersionPoliciesSystemDisableRegistryTools: 0x00000001
HKUS-1-5-21-527237240-1682526488-839522115-1003SoftwareMicrosoftWindowsCurrentVersionPoliciesSystemDisableCMD: 0x00000000
HKUS-1-5-21-527237240-1682526488-839522115-1003SoftwareMicrosoftWindowsCurrentVersionRunTok-Cirrhatus: “”C:Documents and SettingsuserLocal SettingsApplication Datasmss.exe””

[/sourcecode]

Valores Modificados

[sourcecode language=’plain’]

HKLMSOFTWAREMicrosoftWindows NTCurrentVersionWinlogonShell: “Explorer.exe”
HKLMSOFTWAREMicrosoftWindows NTCurrentVersionWinlogonShell: “Explorer.exe “C:WINDOWSBerasJatah.exe””
HKUS-1-5-21-527237240-1682526488-839522115-1003SoftwareMicrosoftWindowsCurrentVersionExplorerAdvancedHidden: 0x00000002
HKUS-1-5-21-527237240-1682526488-839522115-1003SoftwareMicrosoftWindowsCurrentVersionExplorerAdvancedHidden: 0x00000000

[/sourcecode]

Como se puede observar a juzgar por las modificaciones efectuadas en el registro, podemos ver como el malware intenta permanecer en el equipo autoejecutándose cada vez al inicio de sesión modificando las claves ya detectadas en posts anteriores. Sin embargo, mediante la herramienta regshot, hemos obtenido más información acerca de modificaciones efectuadas en el registro, como son:

  • La modificación de la periodicidad de las tareas programadas, pudiendo ejecutar una tarea programada cada 48 horas
  • La modificación de las políticas de seguridad deshabilitando mecanismos, mediante los cuales un administrador podría detectar la presencia del malware como:
  1. Opciones de carpeta  (CurrentVersionPoliciesExplorerNoFolderOptions)
  2. Acceso a la consola o cmd.exe (CurrentVersionPoliciesSystemDisableCMD)
  3. Acceso a herramientas que manipulen el registro de Windows (CurrentVersionPoliciesSystemDisableRegistryTools)
  4. Ocultación de los ficheros ocultos (CurrentVersionExplorerAdvancedHidden)

Estos hallazgos nos permiten entender el porqué en un equipo infectado con el especimen, no se dispone de acceso a la línea de comandos, ni a las opciones de carpetas ni a ciertas herramientas de perfil administrativo.

Por otra parte, monitorizando la creación de threads, se han detectado llamadas a at.exe (tal y como se vio en posts anteriores), cmd.exe, a net.exe y a ping.exe, todas ellas ejecutadas a raíz de un proceso malicioso.

Procesos y Threads en ejecución

Es por ello, que se ha realizado un análisis pasivo de red desde un punto capaz de obtener todos los paquetes enviados y recibidos por el equipo infectado. Dado que se realizan peticiones de resolución de DNS a “google.com” y a “geocities.com“, se ha decidido abrir de forma controlada el acceso a dichos recursos desde la red con el equipo infectado, obtenindo los siguientes resultados:

Captura de red. Resolución de DNS y query a Geocities

“Follow TCP Stream” de la petición efectuada a Geocities

Inicio de Ping hacia tahun.com

Como se observa en el análisis del TCP stream, el especimen intenta bajarse un fichero, aparentemente de texto, el cual, por motivos obvios, ya no se encuentra disponible en la red. Por otra parte, se observa como el equipo también incia un ping (en éste caso sin respuesta) hacia el equipo 17tahun.com (8.5.1.37) que podría ser un equipo de control o bien podríatratarse de un ataque de denegación de servicio distribuído hacia dicho host.

Con ánimo de verificar qué más podría realizar el especimen, y se han arrancado otros dispositivos, los cuales ofrecen servicios típicos de una red Windows, comprobando lo siguiente:

Detección de equipos mediante NetBios

Conexión a recurso compartido anónimo

Petición e infección de recursos compartidos

En las capturas anteriores, se observa como el equipo infectado realiza una conexión exitosa mediante el protocolo SMB al equipo 192.168.1.54, el cual dispone de ciertas carpetas y documentos. Acto seguido, el equipo realiza peticiones tipo “Query” para obtener un listado de recursos disponibles y poder de éste modo escribir en cada uno de los directorios detectados utilizando la nomenclatura de:  “DirectorioDirectorio.exe”. Pudiendo de esta manera:

  • Detectar nuevas víctimas mediante el protocolo Netbios
  • Realizando una búsqueda de recursos compartidos, aparentemente por con autenticación nula ($IPC, openshare en el presente caso, etc.)
  • Recorrido de toda la estructura de recursos compartidos
  • Creación de una copia del especimen en todos y cada uno de los recursos detectados

De ésta manera, el especimen aprovecha los recursos compartidos, típicamente existentes en una Organización, como vehículo de propagación dentro de una red de equipos.

Dejando de lado la actividad de red, todavía nos quedan dos cosillas que revisar;

  1. Los Hooks del Sistema que se han realizado en la interfaz de intercambio de mensajes entre las aplicaciones de Windows.
  2. Obtención de la memoria RAM del equipo infectado

Técnicamente, una función de “Hook” es una función que puede ser insertada en el sistema de mensajes de aplicaciones de Windows de tal modo que a través de la misma poder procesar la información antes de ser procesada por otra aplicación.

Veamos la siguiente imágen,

“Hooks” del sistema de mensajes de Windows

Como se puede ver, cada una de las copias del especimen que se encuentra en ejecución, disponen de un hook del tipo WH_KEYBOARD, WH_MOUSE y WH_MSGFILTER, pudiendo de éste modo, interceptar las acciones del ratón y del teclado (hooks típicos de un keylogger). Sin embargo, no se ha detectado presencia en el sistema de ningún fichero en el cual se pudieran almacenar las pulsaciones del teclado.

Finalmente, con el objeto de acabar el presente post, realizaremos una obtención de la memoria volátil mediante la herramienta MDD a través de la herramienta GMER, la cual nos permite ejecutar comandos en el sistema sin utilizar una interfaz gráfica cmd.exe:

Obtención de la memoria RAM mediante GMER

Una vez finalizado el proceso, podremos analizar desde otro punto de vista las acciones realizadas por el especimen… y quién sabe si encontramos algún password almacenado en la memoria RAM.

Veremos si hay suerte en el próximo post!

Saludos !

[sourcecode language=’plain’]

HKUS-1-5-21-527237240-1682526488-839522115-1003SoftwareMicrosoftWindowsCurrentVersionPoliciesSystem

[/sourcecode]

Demo Free Trial MSSP
Program